Re: Locks on the Bzr repository

[Óscar Fuentes]

Eli Zaretskii <address@hidden> writes:

[snip]

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

Just to clarify:

merge+push has the side effect of twisting the DAG. This means that the
left arm becomes the right, and the right the left. As Eli says, you'll
need to use `bzr log -n0' for seeing the commits that previously were
visible with `bzr log' (sans the -n0) In general, the DAG becomes a
mess. But, worse of all, revision numbers change, because revision
numbering depends on how far from the left is the branch of the DAG that
contains the commit. What now is revision 1000 after a merge+push can be
revision 995.3.2, and some time later 998.5.3.2. This would force us to
use the awkward bzr revision ids for referring revisions.

The Right Thing if you want to accumulate several unrelated local
changes and send them upstream on one batch is to rebase+commit, which
appends your commits to the tip of upstream's branch.

This is not very different from Git. On Git it is not so bad to
merge+push for incoporating your feature branch into mainline (it twists
the DAG sides too, but Git does not make big differences among them.)
However, for sending a series of unrelated commits, the Right Thing on
Git is to rebase+push, which is mostly equivalent to bzr's
rebase+commit.

All this was previously discussed on the list. And we had already some
instances of revision renumbering, so the configuration of upstream repo
was changed for rejecting the operations that would twist the DAG.