Re: Locks on the Bzr repository

["Stephen J. Turnbull" <stephen@xemacs.org>]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen@xemacs.org>
 > > Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>,
 > >     emacs-devel@gnu.org
 > > Date: Sun, 22 Aug 2010 03:59:10 +0900
 > > 
 > >  > For the first kind, it is IMO not very good to have the
 > >  > changes uncommitted upstream for prolonged periods of time,
 > > 
 > > What's your definition of "prolonged"?
 >
 > Never thought about quantifying that.  It seems like a moot point
 > anyway, since there's a request not to lump unrelated changes in
 > the same commit.

It's not a moot point because

 > I could use "ci --local", but that would cause my changes appear on
 > a branch when I finally commit upstream, and require the -n0 switch
 > to "bzr log", so I try to avoid that.

isn't a problem if you rebase.  There's a small race (about 10 minutes
for me on XEmacs with a make; make check[1]) where somebody might commit
while you're rebasing, which would cause push/bound-commit to fail,
but you get a fast-forward (commits all on mainline) when the push
succeeds.  And it will usually succeed.

 > > I'm thinking in terms of simply committing all changes locally
 > > until the end of the work session, then doing the merge to mirror
 > > and push to upstream in a batch at the end of the session.
 >
 > That'd be against the "not lumping together unrelated changes"
 > request.

Why do you think that?  Separate commits are separate commits.  They
are recorded as separate commits in upstream when you push.

 > > How frequently do you commit?
 > 
 > Very frequently, see above.

Heh.  Given that for you each commit goes upstream, that's frequent.
But with git I've used workflows that substitute commits for
autosaves.  That's what I think of as "very frequent".

 > > How finely do you divide changesets?
 >
 > Each changeset deals with a separate feature or bug-fix.  That is
 > how I understand the rules.

That's what I thought, and

 > > I will often make 5 to 10 commits in a session when I'm working
 > > on minor bugs.
 > 
 > Same here, although it's more close to 5 than to 10.

so your workflow in this respect is roughly similar to my own (ie, the
rate of mainline commits is the same, although I tend to break up
anything that involves more than five minutes work into multiple
commits on a branch, in both git and hg).  Ten is unusual for me, but
not so unusual (especially when I'm wearing my RM hat) that I can
afford to ignore the possibility that I'll want to do ten commits and
end up spending 30 minutes minimum waiting for the server.  That's
like 20% of my typical session, and if any of those commits really
hangs I could end up wasting half the session.

 > > I really would not like it if I had to wait even one minute for a
 > > commit of a typo fix.

 > Well, you cannot make a changeset of a typo fix with anything else,
 > unless it's another typo.  The problem is that one rarely finds
 > many typos in one go, except by luck.  So yes, I need to wait
 > before the next commit.  I do other things, like reading mail or
 > work on some other problem in the meantime.

Right.  Context switches are expensive.  I'd rather avoid them,
myself.  YMMV.  The "commit+ pull rebase push" workflow means that all
of my waiting is concentrated on the last three operations, and my
train of thought is never interrupted (because that part of the
workflow is a no-brainer).

 > > No, but if you do a typo fix, commit, then find another typo, 50
 > > minutes (according to the recent report) is a very long time to
 > > wait....

 > Well, 50 minutes _is_ long.  It's more like 3 to 5 here, which is
 > also long, but barely endurable.

You have more endurance than I.  I am not willing to put up with that.

 > > The recommended workflow (at least as Karl and I wrote it)
 > > assumed that "one-commit changes" would be performed in a
 > > separate branch, and merged into the mirror (bound branch) in
 > > batches.
 > 
 > This would again fly in the face of the "don't lump together..."
 > request, AFAIU.

Then there's something you don't understand.  What don't you
understand?  That this workflow involves committing each of several
conceptual changes separately, then one push (or merge + commit in a
bound branch) to send them all upstream?  Or that each commit is a
separate transaction, cherrypickable and logged as such, even after a
pull/push/bound-commit to a different repo?  Or something else?

Footnotes: 
[1]  Not doing the equivalent of "make bootstrap" is a little risky
because we don't have proper dependencies for Lisp ... this matters
mostly for changes to exported APIs not exercised by the build and
test process, or to exported macro internals, both of which are pretty
rare.  I consider the level of risk acceptable.