Re: Locks on the Bzr repository

[Stephen J. Turnbull]

Eli Zaretskii writes:

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

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.
Or one can use a separate branch for each task.  There are lots of
strategies; you don't have to use them if you don't want to.  But some
people would rather spend 5 minutes fiddling with a rebase once a week
(which can be done at your convenience) or so than ever spend 50
minutes waiting for a commit to finish (which blocks you from doing
any other commit, if you depend on lightweight checkouts from
upstream).

 > With the rate of commits to the Emacs repository, the chances that
 > someone "sneaks in a commit before you start your push" are 100%.

That's an exaggeration.  It might be quite high, but if it's really
that high that pushes never succeed, any integration where developers
decided asynchronously when to commit to the public repo (including
both push and commits in bound branches) is going to run into problems.

 > We have committers in all time zones, so there's no time that you
 > are safe.

That depends on one's definition of safe.  My definition of safe is
"my commit is safely in a repository with a known relationship to the
upstream", I can commit any time the fit takes me, and I can push when
I feel like dealing with the costs of cooperation like merge
conflicts.

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

Not if you count *time developer is blocked* instead of *time from
start of operation to end of operation*.  Push is asynchronous; with a
DVCS you don't even need to care if it succeeds, you just work on
another branch.  If it succeeded, you're done.  If not, you make
adjustments and try again later, at your convenience.  (What those
adjustments are depends on the exact workflow.)

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

Sure.  So what?  I don't need to defend a deprecation of "checkout
--lightweight".  I don't like it, but I haven't ever suggested that it
be forbidden.  *You* need to defend your deprecation of "push."

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

All workflows have disadvantages.  Big deal.  That's not a reason for
a general deprecation of "bzr push".

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

No, it has another disadvantage, which is that you can hang up on
concurrent commits by other developers, just as with the push
strategy.  Perhaps it's a little less apparent work because you're
only blocked on merges with conflicts, but once again you're blocked
until your commit succeeds.

It's also somewhat dangerous to just merge everything; a diligent
developer should treat a merge in such case as "my commit needs review
in the new context before committing", really, and what you're doing
is short-circuiting that process.  (Linus famously flamed Dave Miller
for this.)  Any merge (which includes rebasing, which is what davem
was doing) implies your code is now untested until you rerun the
tests.  So if you merge into a bound branch, you're automating commits
of untested code to the public repo.  That may be OK with you (after
all, the test results are only a little bit stale, they're probably
not growing mold and mushrooms yet), but that is what you're doing.

I don't expect this to change your mind about *your* workflows.  But
there are good arguments for other workflows, there are definite
weaknesses in the ones you like as well, and I don't think it's a good
idea to deprecate push-based workflows for those who want to use them.