Re: Locks on the Bzr repository

[Uday S Reddy]

Stephen J. Turnbull writes:

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

Yes, Eli himself said that he wants simplicity, and he suffers the
delays of immediate push's done by the bound branch as a result of
that.  I think most developers here would rather not open up task
branches for small fixes.  I think 

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

Yes, I am better able to understand this view point now as a result of
this debate.  Note that Bazaar's presentation of the above merge is:

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

and I had orignally missed the idea that B1 should be thought of
really as a successor to 0 = A1.  So, going from An to B1 includes
first a backwards time travel (An -> A1) and going from Bm to 1
includes a fast forward (A1 -> An).  Bazaar's presentation makes it
appear as if B1...Bm have been rebased but, in reality, they are
the original commits that are just being stuck in the middle of the
mainline. 

If one is doing a bisection to find a problem, one would do it first
on the mainline, find that the fault occurs somewhere between An and
1, and then do a second bisection on B1...Bm.  If one is doing this by
hand, it is quite confusing in having to deal with A1 again while
looking through B1...Bm.  I would ask, "A1 works ok, but what is B1
adding that is breaking things?"  But, oops, B1 is doing something
entirely different!

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

I think the loss of information is a myth.  Information will be lost
only if the VCS deliberately loses it.  There is no reason why the VCS
can't keep track of B1...Bm in terms of patches on A1 as well as
patches on An.  You can then rebase it forwards and backwards as often
as you need to, to get the information you want.

Rethinking the issues now, it is becoming clear to me that there are
two independent, but related, issues:

- Storage: You want to store a history that is accurate so that you
can go back to it when you want to.

- Presentation: You want to produce a rebased history for review and
forensic analysis because it is easier to deal with.  One might want
to go back to the accurate history if the rebased history doesn't
work.

I notice that Stefan proposed essentially this idea in the bazaar
developers list, and Michael Haggerty has a more elaborate
presentation of the issues here:

http://softwareswirl.blogspot.com/2009/04/truce-in-merge-vs-rebase-war.html

Cheers,
Uday