Re: Locks on the Bzr repository

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: Andreas Schwab <schwab@linux-m68k.org>,
>     jan.h.d@swipnet.se,
>     monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Fri, 20 Aug 2010 19:15:38 +0900
> 
> Eli Zaretskii writes:
> 
>  > Plus, pushing many unrelated commits has a drawback as not showing
>  > in "bzr log" unless you also use the --include-merges (or -n0)
>  > switch, which makes "bzr log" significantly slower.
> 
> No.  Push simply synchronizes the histories, and IIRC to push in bzr
> you must be a superset of the remote repo's history.  So what
> matters to the bzr log view is how you manage your local repo

If I ever only "bzr merge" from the remote repository, won't my pushes
to it cause my local commits appear on a branch, and the point of push
appear as a merge to mainline?  If so, that's what I meant.

> You may need to rebase if somebody sneaks in a commit before you
> start your push

With the rate of commits to the Emacs repository, the chances that
someone "sneaks in a commit before you start your push" are 100%.  We
have committers in all time zones, so there's no time that you are
safe.

> but I would imagine you normally need less locking and a lot less
> time if the push succeeds.

This needs testing and measuring; I won't believe it until I actually
see it.  The time to push is still governed by network traffic, which
takes most of the time, about 90%, of a commit as well.

And even if it is true that this is faster, what you describe hints on
a much more complex workflow that needs a much more diligent user who
knows much more about bzr than most contributors.  Any blunder there,
and you need to work much harder and at least partially by hand to
restore the situation where your branch is "a superset of the remote
repo's history".  So this workflow still has disadvantages, even if it
faster (which I very much doubt).

> It's true that if you only ever use bound branches, all your commits
> must end up on the mainline, and that may be the best strategy for
> some people.  But other people like to commit more frequently and/or
> offline.

Me too, but having a separate local branch and merging locally with a
bound branch has all the advantages of the frequent fast commits, and
only one disadvantage -- the commits appear on a branch (unless I
rebase).  The workflow is much simpler, though.  That's why this is
what I do when I work on something that is not a 5-min job.