Re: Locks on the Bzr repository

[Uday S Reddy]

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.  I am surprised that many emacs developers are ok with it, but
my own experience is that a few days of testing through daily use is
necessary for me to develop confidence in some of my fixes.  I would
feel very exposed if I can't commit fixes to my branch without
publishing them at the same time.

>  > 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.  

No, I don't mean to say that merge itself is a problem.  But, Bazaar's
recommendation to use merge *instead of* rebase is a problem.  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 am actually happy with Bazaar's presentation of history.  A
straightline history is good for doing bisection when you need to.
The practice of hiding merge histories from the top-level is also nice
for ignoring unnecessary detail.  

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.

Maybe I am one of those "users coming from central VCS tools with poor
merge tracking".  But I don't see the new ways being necessarily
superior.  

Cheers,
Uday

PS I am trying to keep this part of the thread focused so that Richard
has a coherent story to deal with.