Re: Locks on the Bzr repository

["Stephen J. Turnbull" <stephen@xemacs.org>]

Uday S Reddy writes:

 > On the other hand, distributed maintenance with a clean management
 > of history necessarily involves rebase.

This is not true in general.  In particular, the workflow suggested in
BzrForEmacsDevs can produce a "clean history"[1] without rebase,
although it may require remerging branches before pushing because of
the race condition.

Other alternatives include the pull workflow (ie, synchronization by
the maintainers -- you can quibble about whether that's "really
distributed", if you like, and I sympathize, but it is an option for a
project), and an automated patch queue as used by the Bazaar project
itself.

 > Bazaar's solution is to provide merge, which lumps each batch of
 > fixes together into a subhistory without concern for any logical
 > coherence among the changes.

That is not a problem of merge.  All VCSes provide merge.  It is a
problem of the workflow and a matter of taste.  Specifically, whether
you care if even single commits (off mainline) are "covered" by a
merge commit (on mainline).  The Bazaar developers consider this a
natural consequence of distributed development, and have adapted the
log command to normally display only the mainline.  (git and Mercurial
have options to do this, or to display only merge commits, which has a
similar effect.)  There remains a small problem of coming up with an
appropriate log message for the merge commit, but in the specific case
of a single commit, you just copy the commit message into the merge
log message.

Some people consider such a history unsightly, and strongly prefer to
rebase.  But this is a matter of taste.

 > In the absence of rebase, the Emacs developers are forced to
 > synchronize with the mainline for each commit they want to do.

This is only true if you insist that every commit (or every commit on
mainline) in the public repo be tested.  But in that case, rebase
doesn't save you any synchronization compared to non-rebase.

There is are at least two alternatives to rebase.  The first is to use
multiple workspaces, one per task, even trivial tasks.  The second is
to use bzr send for each logical changeset, save the bundles to disk,
and then merge them one after another.

If it is acceptable for the mainline to be temporarily untested, then
the developer can test each commit after merging and pushing.  Then of
course they need to fix any problems discovered in a timely fashion.
An alternative is that only the result of the last merge must pass the
tests; then it's reasonable to test before pushing (although not from
"make bootstrap" probably).

 > It would be best if they provide rebase and provide sufficient
 > warning, and leave it to the project managers to use them wisely.

If a project is going to use rebase, git is *strongly* recommended, as
it not only provides rebase, but several other features for creating
"nice" histories such as filter-branch.

Footnotes: 
[1]  AIUI in Emacs practice a "clean history" means that each
conceptual change, whether it is a single typo fix or integration of
a new garbage collector or internal character coding, is represented
by one commit on the mainline.  A large feature like a new garbage
collector might involve many commits on a branch, however.