Re: Locks on the Bzr repository

[Eli Zaretskii]

> From: Uday S Reddy <address@hidden>
> Date: Fri, 20 Aug 2010 23:41:13 +0100
> 
> >> Sure.  So don't do that.  One (probably for values of "one" != "eliz")
> >> can pull instead, and rebase when necessary to get that to succeed.
> >
> > Please show this workflow in more detail.  Without the details, it's
> > hard to tell what you suggest.  You could be thinking about things
> > possible with git, but not with bzr; it happened in the past.
> 
> I think one needs to do a pull before each commit, to be safe.  (Seems to be 
> the same as update-commit cycle for bound branches.)
> 
> If you have already done a series of commits and lost the opportunity to 
> pull, 
> then you have to rebase.
> 
> If even that seems too far out, then you have to make your changes into a 
> separate branch and merge it in later.

Well, Stephen refused to tell more, citing my imaginary unwillingness
to know.  (Since when asking a question means you don't want to know
the answer?)  So I guess we will never know what Stephen was talking
about.

Btw, pull is only possible when the branch didn't diverge from
upstream, which means it is not suited well for a branch where you do
development.  At least AFAIU.  I'm not even sure it will agree to do
its job if you have uncommitted local changes.

Merging into a local branch is what I had in mind, and the
disadvantage with the "bzr log" output I talked about applies to that
workflow.  To me, it is a significant disadvantage: I use "bzr log" a
lot, and it is painfully slow with the -n0 switch.

As for rebase, I don't really understand what you suggest, and how it
will help with an unbound branch where you develop.  Perhaps you could
elaborate.  (I know what's a rebase and how to do it with Bazaar.)

> However, we get to use our local mirror of the trunk as if it were a local 
> branch.  We can commit to it without affecting anybody else and do a public 
> commit only in the end.  We can commit to it as often as we please, keep a 
> careful log, do enough testing etc. And, this local branch can magically turn 
> back into a proper mirror as soon as we do a rebase-push.  You can't get this 
> with bound branches.  Your local branches have to be necessarily separate 
> branches, whose histories will appear as merges in the mainline.

Sure.  But that's in theory.  In practice, you also need to consider
what kind of changes you make locally.  At least for me, there are 2
main kinds: bug-fixes and development of significant new features.
(There's a third kind as well: when I need to make changes for the
MS-DOS build, but I don't think this part will be interesting for
anyone but myself.)

For the first kind, it is IMO not very good to have the changes
uncommitted upstream for prolonged periods of time, because people are
using the development code, and the bugs annoy them.  So you'd like to
commit those to upstream frequently.  And if you commit frequently,
the proposed rebase-push workflow (IIUC) is not a real improvement,
perhaps even a nuisance, because it adds the overhead of the rebase
and does not save me from frequent slow commits to the master
repository.  And if your local commits have bug-fixes and new features
interspersed, and you want to commit just the bug-fixes, won't the
workflow you need for such cherry-picking become even more
complicated?

For the second kind of changes, I don't see how doing that on an
unbound "mirror" branch is different from a separate branch whose
purpose is development.  A separate branch has the advantage of
keeping the development separate from mainline, so I cannot by mistake
commit unfinished code to upstream.  It also lowers the mental burden
on my mind, by keeping things spatially separated.  Merges are
painless either way; I generally find bzr doing its job very well when
I merge.

So bottom line, I see no advantages to using an unbound branch which
mixes changes of different types.  I agree it's probably possible to
do all that with an unbound branch, but I don't see how it would
relieve the pain of slow commits and slow updates/merges from
upstream, which both are slow due to network traffic bzr incurs when
it uses SFTP.

> We use separate local branches as well, when they are appropriate.  But we 
> are 
> not forced to use them all the time.  (Generally, I am happy to use the main 
> branch for a few days worth of work where I can see the end clearly.  I use 
> separate branches for things that might take a few weeks, or things of a more 
> open-ended nature.)

Well, you see, for me, "a few days worth of work" means in practice a
few weekends of work, because I have almost no time on weekdays for
any significant work.  A week's worth of commits to upstream by others
is most of the time significant enough to make it a PITA when you have
local changes, because there isn't a week that I don't find some small
bug I want to fix and commit almost immediately, to let others enjoy
the fix.

> With bound branches, your branch is locked up until the commit goes
> through.  You can't do anything while you have uncommitted changes
> in your source.

Why would you say that?  That's not true.  Nothing prevents me from
editing while "bzr ci" churns away.  The system is not locked, only
(some) bzr operations will fail.  But most of the development is not
about bzr ops, its about using the editor, the compiler, and other
development tools, none of which are locked up when "bzr ci" runs.

> With unbound branches, we can continue working on the source even
> when push is running in the background, because the source tree
> doesn't have any uncommitted changes.  We can also give up on the
> push if necessary and continue committing to the branch.  The
> advantage seems quite clear to me.

Seems you think that when I'm done with developing one feature or
bug-fix, I immediately proceed to committing the next one.  But that's
not so, at least not here.  Before I'm ready for the next commit,
either locally or to upstream, I need to develop and test it.  And
that part, which is what I do most of the time, is not blocked by a
running commit.

> > No big deal.  But the disadvantages of each workflow need to be well
> > understood before making a decision which one to use.
> 
> I can't believe that you guys really understood the disadvantages of your 
> current workflow before settling on it.

Not entirely, which is why I constantly revise it and make amendments.
But that doesn't mean I shouldn't consider the merits and demerits
beforehand.  After all, most bzr commands are common to all workflows,
and so getting experience with them makes you smarter when making
decisions about workflows you didn't yet try.

> The most illuminating revelation I found in Stephen's post is that,
> with bound branches, every commit is a merge.  Most of the time, it
> is untested and unsafe.  This is the biggest disadvantage of all, if
> you ask me.

I don't understand this argument at all.  In fact, I think it's plain
false.  My workflow in a bound branch is this:

  brz up
  [build the current upstream]
  [some minimal sanity checks to make sure upsteam works]
  [make changes]
  [build and test the modified binary]
  [repeat the sanity checks, fix anything that became broken]
  [bzr up]
  [if there are any changes upstream, build and test again]
  [repeat last two steps until "bzr up" brings no changes]
  bzr ci

Now please tell me how can I commit code that is "untested and unsafe"
with this workflow?  What am I missing?

> It also occurs to me that, by asking everybody to use bound
> branches, you have massively increased the contention on your public
> repo and the server.  That is making your problems worse.

For the record, I didn't write the recommended workflow (I don't even
use it to the letter).  It was written by 2 people who know a lot
about Bazaar and dVCSs.  So I trust them to have weighed the merits
and demerits when they decided on that workflow.

Having said that, the Emacs wiki is free for anyone to suggest
alternative workflows, so if you think there are better alternatives,
feel free to advertise them.  There's already one such alternative
there, I see no reason why there shouldn't be more of them.