Re: Locks on the Bzr repository

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > isn't a problem if you rebase.
 > 
 > Stefan says bzr's rebase is unreliable.

I know it's limited, but I'm pretty sure it works fine in the simple
case I described.

 > I just completely misunderstood the use-case you were describing.

Ah. OK, no problem.

 > indeed.  The only problem is with having the changes on a branch
 > instead of mainline of the history, unless rebase is used.

Yeah, as I wrote elsewhere, bzr doesn't really give you a good way to
work around that (unless you are in a position to pull contributions
into the project mainline, but that doesn't work for Emacs).

 > There's one other problem with holding back commits to minor
 > problems: someone else could solve the same problem in the
 > meantime.  Apart of the obvious social issues ("I was the first to
 > fix it"), there's the issue of wasted effort.

I don't consider that wasted effort, actually.  The person who gets
there first usually gets the credit, the second person is a perfect
candidate to review. :-)

 > I guess no one seriously considered all these issues

Er, no.  Several of us told you, at greater or lesser length, that
these were going to be issues, and that git was a much better fit for
Emacs.  That advice was completely ignored.

 > because we believed (and still do) that bzr will eventually become
 > faster on Savannah.  Perhaps one day we will abandon that hope and
 > turn to resolving these issues instead.

I don't think you can, without redesigning bzr.  Faster, yes, but this
issues about mainline confusion, no.