Re: Locks on the Bzr repository

[Eli Zaretskii]

> Date: Sat, 21 Aug 2010 10:38:46 +0100
> From: Uday S Reddy <address@hidden>
> Cc: Uday S Reddy <address@hidden>, address@hidden
> 
> Jan Djärv writes:
> 
> > You are ignoring the fact that work usually doesn't happen in the bound 
> > branch, but in a separate task branch.  We can continue to work there while 
> > the bound branch commits.  I don't see much difference.
> 
> If there isn't "much difference" then why is push being discouraged?

The only place on the wiki which could be considered as "discouraging"
push is this:

  It might occur to you to save some effort by just doing bzr push
  directly to the upstream master from inside the TASKNAME branch:

        cd $DEVHOME/emacs/TASKNAME
        bzr push sftp://address@hidden/srv/bzr/emacs/trunk/

  *Do not do this* -- it can cause history to be displayed in a strange
  way in the upstream master, any mirrors or branches of it, and your own
  branch later. Search for the word “hidden” in
     http://lists.gnu.org/archive/html/emacs-devel/2009-11/msg01021.html
  for more details.

IIRC, this was written by Stephen and Karl, and I don't see anything
wrong with this warning.  Do you?

> If you want to work on the main branch rather than task branches, then
> it does make an important difference, as Stephen and I have pointed
> out.  Here, an unbound main branch is a lot more flexible and it will
> reduce the contention on the central repo.

As I wrote in an earlier post, I don't see the extra flexibility.  I'm
awaiting your response to that.

> > 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.
> 
> If Eli is trying to avoid levels in histories, then he *must be*
> working on the main branch.

I'm trying to keep the history linear whenever possible, yes.  If you
think this is not a good idea on its own right, please tell why.

> And, he is stung by the bound main branch.  Using an unbound main
> branch will immediately improve things.

Again, I don't see how am I "stung" and how an unbound branch will
improve things.

> Note that he also raised a logical problem.  If you open a separate
> branch for your work, then you don't want to put many unrelated
> commits in it.  That will make it appear as if they were related
> commits at the top level.  Using bound branches will encourage people
> to put unrelated commits in task branches.

If you do ALL of the work in a task branch, yes.  But I don't think
that's the right workflow, and that's not what I use.  I use task
branches for 2 kinds of jobs:

  . prolonged development of features

  . forensics: debugging some issue that needs switching to earlier
    versions, e.g. with "bzr bisect" or "bzr revert -rNNN" (later I
    get rid of all the traces of these revert commands by pulling from
    the main branch with "bzr pull --overwrite")

> Whichever way I look at it, I don't see any upside to using bound
> branches, but plenty of downside.

Well, would you please list those downsides together?  They must have
been lost in the argument, because I don't see them.  At most I've
seen a single downside you cited -- that further development is
somehow stuck until the commit from the bound branch finishes.  As I
wrote, I think this claim is simply false.