Re: Locks on the Bzr repository

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 21 Aug 2010 13:31:29 +0100
> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>,
>     emacs-devel@gnu.org
> 
> Commiting/sychronizing "frequently" is still better than commiting
> instantly.  It gives you a choice as to how frequently you
> synchronize.  That might depend on the urgency of the fixes and server
> contention levels.  Bound branches remove that choice.

Strictly speaking, they don't.  There's still "ci --local".

Anyway, I don't care much about this choice, because I always choose
to sync and commit.  I already explained the reasons.

> As for interspersing bug-fixes and new features, I would pick and
> choose depending on the situation.  A half-finished new feature
> sitting in the trunk doesn't hurt anybody.  I might leave it in.

Really??  I doubt many developers will do the same.  I certainly
won't, not as long as the development code is used by many people.

> (People are expected to use the new feature only after it gets into
> the NEWS file.)

I actually read the ChangeLog files each time I resync.  I won't be
surprised if many others did the same to learn about news.  There's
also the emacs-diffs mailing list which is great for watching new
developments; all commits go there, so NEWS don't count.

> Or, if I don't feel comfortable about it, I would
> probably push my current main branch as a task branch, reset the main
> branch to the old state (using uncommit), and attend to the urgent bug
> fix in the main branch.  Or, I might do the urgent bug fix in a new
> mirror of the central repo and push it.  It will then reappear as part
> of rebase in my main branch.  So, there are lots of ways of doing it.

Yes; and all of them are quite complicated and more error-prone than
the simple ones.  To me that means they should be used only when
necessary (which I do), not as a matter of routine.

> 1. Allows you to synchronize with central repo less frequently.
> 
> 2. Allows you to choose when to synchronize.

These two are the same.

> 3. Keeps your related commits to the mainline together.

This one is unrelated to boundness of the branch.  I can do the same
in a bound branch -- I just need to wait with committing until all the
"related" changes are ready to go.

> 4. Allows you to go from bug-fixing mode to (small) development mode
> and back, without much pain.

Not without some pain.

> 5. Allows you to choose between many different workflows, and even to
> switch from one to the other on the fly, whereas bound branches seem
> to allow only one workflow.

Since I have local unbound branches anyway, this is not an advantage
at all.  Whenever I need this, I simply switch to one of the local
branches.  There are bzr tricks to move all your uncommitted changes
to a different branch, and I use them in that case.

> Having always used unbounded branches, I came into this discussion
> wanting to learn why bound branches are being used by you guys.  I
> still don't know why.  But I can see that it makes you feel a lot more
> comfortable. 

As I wrote elsewhere, the only real advantage is the simplicity of the
workflow.  To me, that is important, as is the fact that simplicity
makes my work less error-prone.  With the little time I have, any
errors on my side could take days to be fixed, and I don't like to
cause long-term breakage.  YMMV.