[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Locks on the Bzr repository
From: |
Eli Zaretskii |
Subject: |
Re: Locks on the Bzr repository |
Date: |
Sat, 21 Aug 2010 22:56:27 +0300 |
> From: "Stephen J. Turnbull" <address@hidden>
> Cc: Uday S Reddy <address@hidden>,
> address@hidden
> Date: Sun, 22 Aug 2010 03:59:10 +0900
>
> > For the first kind, it is IMO not very good to have the changes
> > uncommitted upstream for prolonged periods of time,
>
> What's your definition of "prolonged"?
Never thought about quantifying that. It seems like a moot point
anyway, since there's a request not to lump unrelated changes in the
same commit. (What would you write as a commit message for such a
commit, anyway?) So I normally commit a change as soon as it's ready
and tested, and if that's in a bound branch, it goes upstream. In
practice, this tends to happen every hour or two, when the changes are
quick and simple (for the other kind I do it in a separate branch).
I could use "ci --local", but that would cause my changes appear on a
branch when I finally commit upstream, and require the -n0 switch to
"bzr log", so I try to avoid that.
> I'm thinking in terms of
> simply committing all changes locally until the end of the work
> session, then doing the merge to mirror and push to upstream in a
> batch at the end of the session.
That'd be against the "not lumping together unrelated changes"
request. Maybe I interpret it too strictly, but it will take Stefan's
or Chong's word to make me change this.
> How frequently do you commit?
Very frequently, see above.
> How finely do you divide changesets?
Each changeset deals with a separate feature or bug-fix. That is how
I understand the rules.
> I will often make 5 to 10 commits in a session when I'm working on
> minor bugs.
Same here, although it's more close to 5 than to 10.
> I really would not like it if I had to wait even one minute for a
> commit of a typo fix.
Well, you cannot make a changeset of a typo fix with anything else,
unless it's another typo. The problem is that one rarely finds many
typos in one go, except by luck. So yes, I need to wait before the
next commit. I do other things, like reading mail or work on some
other problem in the meantime.
> > > With bound branches, your branch is locked up until the commit
> > > goes through. You can't do anything while you have uncommitted
> > > changes in your source.
>
> > Why would you say that? That's not true. Nothing prevents me from
> > editing while "bzr ci" churns away. The system is not locked, only
> > (some) bzr operations will fail. But most of the development is
> > not about bzr ops, its about using the editor, the compiler, and
> > other development tools, none of which are locked up when "bzr ci"
> > runs.
>
> No, but if you do a typo fix, commit, then find another typo, 50
> minutes (according to the recent report) is a very long time to
> wait....
Well, 50 minutes _is_ long. It's more like 3 to 5 here, which is also
long, but barely endurable.
> I imagine it would also be a bad idea to continue to work on
> any of the files currently being committed, as if the commit fails you
> need to disentangle the changes by hand.
Right, you need to refrain from saving. But if I have a long series
of changes to the same files, it generally means they belong to some
larger feature, so I should do it in a local branch anyway.
> The recommended workflow (at least as Karl and I wrote it) assumed
> that "one-commit changes" would be performed in a separate branch,
> and merged into the mirror (bound branch) in batches.
This would again fly in the face of the "don't lump together..."
request, AFAIU.
- Re: Locks on the Bzr repository, (continued)
- Re: Locks on the Bzr repository, Leo, 2010/08/21
- Re: Locks on the Bzr repository, Tom Tromey, 2010/08/21
- Re: Locks on the Bzr repository, Leo, 2010/08/21
- Re: Locks on the Bzr repository, David De La Harpe Golden, 2010/08/22
- Re: Locks on the Bzr repository, Andreas Schwab, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Leo, 2010/08/22
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/22
- Re: Locks on the Bzr repository,
Eli Zaretskii <=
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/21
- Re: Locks on the Bzr repository, Stefan Monnier, 2010/08/21
- Re: Locks on the Bzr repository, Uday S Reddy, 2010/08/22
- Re: Locks on the Bzr repository, Teemu Likonen, 2010/08/22
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/22
- Re: Locks on the Bzr repository, Stephen J. Turnbull, 2010/08/22
- Re: Locks on the Bzr repository, Richard Stallman, 2010/08/23
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/23
- Re: Locks on the Bzr repository, Glenn Morris, 2010/08/23
- Re: Locks on the Bzr repository, Eli Zaretskii, 2010/08/23