Re: Locks on the Bzr repository

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

Uday S Reddy writes:
 > Stephen J. Turnbull writes:
 > 
 > > 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.
 > Yes, the current workflow does achieve clean history, but at the
 > cost of removing any gestation period for fixes that the developers
 > might want.

Not at all.  I'm not sure if Eli would do a "one-commit" patch in a
separate workspace, and then merge, but he's said several times now
that he uses multiple workspaces, at least for feature branches.  It's
certainly possible to have a "feature branch" for a one-line patch.
So you put your change in a separate workspace and test it there.  You
merge when you're happy with it.  This is nicer with rebase, I admit,
but it's not impossible without it.

 > Bazaar developers do seem to understand that merges doesn't give
 > you a clean history (at least in Bazaar's way of presenting
 > history), but they underrate its importance.

I don't understand.  Especially since you say you're happy with bzr's
presentation of history.

 > Moreover, I think that even normal merged branches would benefit
 > from rebasing.  Otherwise, they involve a backwards time travel for
 > the initial commit, which is confusing during review and even worse
 > when you have to bisect for a change later.

There are multiple schools of thought about this.  Specifically,
bisecting on

  A1 -- ... -- An
 /               \
0                 1
 \               /
  B1 -- ... -- Bm

vs. bisecting on

0 = A1 -- ... -- An -- B1 -- ... -- Bm = 1

will indeed identify a particular Bi commit as the source of the
problem.  However, many developers feel that understanding that A1 and
B1 were both designed in the context of commit 0 is important for
understanding the evolution of A and B.  This information is lost by
the rebase.  And in fact, it may be that the design of B is cleaner or
more central to future development, so that you really want to fix A,
and leave B alone.  So bisecting may lead to poor selection of fixes.

 > But I don't see the new ways being necessarily superior.

I'm not sure what you mean by "necessarily" superior.  They are not
globally superior; indeed, to take advantage of their features
requires at least minimal investment in learning new patterns (even
for bzr, which takes pains to provide commands to emulate
"traditional" workflows), and taking substantial advantage normally
requires change in workflows.

In the projects I've seen make the change, there is almost always a
division, with the most productive contributors (by patch or LOC
count; of course there are other important measures of productivity)
strongly in favor of more distributed practices and willing to make
some investment, and less productive ones happy with the status quo,
and opposing the "unnecessary" change.