Re: Locks on the Bzr repository

[Eli Zaretskii <eliz@gnu.org>]

> From: "Stephen J. Turnbull" <stephen@xemacs.org>
> Cc: jan.h.d@swipnet.se,
>     schwab@linux-m68k.org,
>     monnier@iro.umontreal.ca,
>     emacs-devel@gnu.org
> Date: Fri, 20 Aug 2010 22:44:28 +0900
> 
> 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.

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.

And please drop the ad hominem, you are (again) incorrectly assuming
that I don't use distributed workflows.  You can see that this is not
so if you look at my commits in "bzr log" .

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

I do want and do use some of them.  Please don't mistake a critical
opinion for rejection.  Instead, back up your opinions by valid
arguments, and maybe I will be able to actually learn something from
you.

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

I don't use lightweight checkouts.  I use one bound branch and 2 or 3
local branches.  I have no problems with local commits, which I use a
lot.  The problem happens when I need to commit to the master
repository.  I need to do that from time to time, because my local
commits are not available to others, so if I fix bugs, my fixes will
not be good to anyone until I commit to upstream.  And doing so is
painfully slow, and there seems to be no way around it.  On top of
that, sometimes a commit fails, because someone holds a lock or
because some other commit was "sneaked" in in the meantime.  So I need
to watch the commit and make sure it succeeds, or start another one if
it doesn't.  So please don't tell me this is asynchronous, because it
isn't, at least not entirely.

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

How do you know?  How frequently do you commit to the Emacs repo?

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

You are talking from the POV of someone who has a lot of time on his
hands, or has a fast enough connection to make the delay
insignificant.  By contrast, I have maybe a few hours during a weekend
to work on Emacs, with maybe half an hour on weekdays.  Every delay
counts, and there's no "at my convenience".

> *You* need to defend your deprecation of "push."

I don't deprecate "push", so I have nothing to defend.

> All workflows have disadvantages.  Big deal.

No big deal.  But the disadvantages of each workflow need to be well
understood before making a decision which one to use.  And the
considerations might well be different given one's personal
circumstances and connectivity.  Careful examination of the advantages
and disadvantages does not constitute deprecation, and should not be
treated with derogation.

>  That's not a reason for a general deprecation of "bzr push".

I don't deprecate "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.

As long as you commit to the master repo, you will become blocked
sometimes.  And if you think that my development is blocked while the
commit grinds away, then you are simply wrong, because I have
additional branches where I can and do develop in the meantime.  But
the slow commits that sometimes fail after many seconds if not minutes
are an annoyance anyhow, and no amount of preaching the "push" ways
can do anything about it.

> 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

Exactly.  And as I explained in another mail in this thread, this
calls for testing after I merge, which is one factor why the chances
are high to have some other commit sneaked in before I commit.

> and what you're doing is short-circuiting that process.

What am I doing that short-circuits this 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.

Don't ass-u-me that I'm committing without testing after the merge.

> I don't expect this to change your mind about *your* workflows.

Looks like you have no idea at all what _is_ my mindset regarding the
possible workflows.  Perhaps you think you are talking to someone
else.

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

I don't deprecate "push.