Re: Locks on the Bzr repository

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>,
>     emacs-devel@gnu.org
> 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.