From: "Stephen J. Turnbull" <stephen@xemacs.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>, emacs-devel@gnu.org
Subject: Re: Locks on the Bzr repository
Date: Sun, 22 Aug 2010 03:59:10 +0900 [thread overview]
Message-ID: <87vd737pxd.fsf@uwakimon.sk.tsukuba.ac.jp> (raw)
In-Reply-To: <83aaogpcbu.fsf@gnu.org>
Eli Zaretskii writes:
> 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?)
When you consistently ask for details before you have enough
understanding of the theory, or at least the pragmatic constraints.
Anyway, I don't use bzr in anger so my actual workflows aren't going
to be particularly useful.
> So I guess we will never know what Stephen was talking about.
No, I changed my mind about posting to the thread since Jan mentioned
BzrForEmacsDevs and the recommendation for binding the mirror branch.
> 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.
D'oh. You just don't ever want to do development in your mirror
branch (unless it's bound). The reason this is a problem in bzr (and
to some extent hg) is that branches are heavyweight; you don't want
scads of them being made automatically for internal operations. So
the user has to make mirror branches explicitly when needed. git
makes branching extremely lightweight, and therefore need not hesitate
to use mirror ("tracking") branches which are read-only to the user,
and hardly visible.
> Merging into a local branch is what I had in mind,
Really, I'm coming to believe that bzr is fundamentally unsuited to
radically distributed development (which Emacs approximates, since it
has a fairly large group of committers and no required synchronization
protocol). Merging into a local branch should not require thought!
> 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.)
The workflow should be something like
0. work in "work", a branch of "mirror" (local) which is in turn a
branch of "trunk" (on Savannah)
1. pull from "trunk" into "mirror"
2. rebase "work" on "mirror"
3. repeat 0-2 until done
4. cd to mirror & pull from "work" into "mirror" (this will always succeed!)
5. push from "mirror" to "trunk"
6. if 5 succeeds, you're done (for now, go to 0 to start the next change)
7. else pull --overwrite from "trunk" into "mirror"
8. goto 2
> 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.)
That's interesting in itself for anybody maintaining an optional
feature or different platform, I should think.
The other thing is that you have multiple development branches. This
is where the rebase-based workflow is attractive to me. The reason is
that I generally want to have an easy way to diff against the branch
parent (so I don't want to merge into the local branch and have mixed
sequences of trunk and local commits, even if the VCS could
theoretically handle it) but I do want my branch to incorporate the
latest trunk commits.
I guess this could also work with the mirror being a branch bound to
"trunk", but it makes me nervous because of the incompleteness of bzr
documentation; often it's not obvious what checkouts (lightweight or
heavyweight) will do in any given situation. Also, you could have a
script that will do the rebase step in several related branches with
one pull, avoiding unnecessary network traffic.
> 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"? 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.
> 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.
How frequently do you commit? How finely do you divide changesets? I
will often make 5 to 10 commits in a session when I'm working on minor
bugs. I really would not like it if I had to wait even one minute for
a commit of a typo fix. (I always separate typo fixes from "real bug"
fixes, and although I do batch typo fixes when I make them one after
another, I don't rebase just so that I can group all typo fixes in a
single commit.) At least when I push to my launchpad branch of
Mailman, there are many seconds of setup cost, which is only incurred
once per push. And then I go for coffee or dinner or read mail. (Of
course, I don't have a race condition since it's a private branch.
But I do have to check for success.)
> 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?
Yes. I don't do that in bzr. (It's no big deal in git because of the
interactive rebase feature.)
> > 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.
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.... I imagine it would also be a bad idea to continue to work on
any of the files currently being committed, as if the commit fails you
need to disentangle the changes by hand. bzr is no help because it has
no record of which changes are part of the intended commit, and which
ones aren't. You could avoid saving your post-bzr-ci work, and use
the difference between the buffer and the file, but that seems a bit
fragile.
> 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?
That workflow is safe, because the last thing you do before committing
is test (the very last bzr up is a no-op, of course). That is what is
required for a safe workflow. But it's very tempting to not do tests
after bzr up succeeds without conflicts, and experience in many
projects is that it is a common practice to omit testing after a merge.
> > 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.
That is definitely not true. 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. Thus it's equivalent to a pull/rebase/push
workflow for the purpose of hits on the public repo.
It was others who insisted on recommending work *in* the bound branch,
which could increase the burden on the server (but I don't know how
much). IIRC, however, that is documented in a separate wiki page, and
not as part of the BzrForEmacsDevs recommended workflow.
However, I doubt that's really a big problem. The real problem is
abysmal administration at Savannah (at least for this purpose), and
maybe bzr's inherent slowness. I don't understand the stale locks
problem; at least it's not frequently reported on the bazaar list.
(That may be because so few people use dumb servers for the trunk
repository, if it's a bug restricted to dumb servers.)
next prev parent reply other threads:[~2010-08-21 18:59 UTC|newest]
Thread overview: 198+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-19 15:40 Locks on the Bzr repository Stefan Monnier
2010-08-19 15:52 ` Andreas Schwab
2010-08-19 16:07 ` Jan Djärv
2010-08-19 16:36 ` Andreas Schwab
2010-08-19 20:06 ` Jan Djärv
2010-08-19 21:49 ` Andreas Schwab
2010-08-20 6:22 ` Jan Djärv
2010-08-20 7:40 ` Andreas Schwab
2010-08-20 8:57 ` Eli Zaretskii
2010-08-20 9:13 ` Andreas Schwab
2010-08-20 9:22 ` Eli Zaretskii
2010-08-20 11:35 ` Andreas Schwab
2010-08-20 12:24 ` Eli Zaretskii
2010-08-20 12:56 ` Óscar Fuentes
2010-08-20 13:29 ` Andreas Schwab
2010-08-20 14:43 ` Eli Zaretskii
2010-08-20 10:15 ` Stephen J. Turnbull
2010-08-20 11:39 ` Andreas Schwab
2010-08-20 12:42 ` Stephen J. Turnbull
2010-08-20 12:23 ` Eli Zaretskii
2010-08-20 12:52 ` Óscar Fuentes
2010-08-20 13:33 ` Andreas Schwab
2010-08-20 14:46 ` Eli Zaretskii
2010-08-20 15:31 ` Andreas Schwab
2010-08-20 13:44 ` Stephen J. Turnbull
2010-08-20 15:19 ` Eli Zaretskii
2010-08-20 22:41 ` Uday S Reddy
2010-08-21 8:36 ` Jan Djärv
2010-08-21 9:08 ` Eli Zaretskii
2010-08-21 10:30 ` Jan Djärv
2010-08-21 10:41 ` Eli Zaretskii
2010-08-21 10:47 ` Jan Djärv
2010-08-21 17:04 ` Thien-Thi Nguyen
2010-08-22 7:39 ` Stephen J. Turnbull
2010-08-23 3:15 ` Thien-Thi Nguyen
2010-08-21 9:38 ` Uday S Reddy
2010-08-21 10:30 ` Eli Zaretskii
2010-08-21 10:37 ` Jan Djärv
2010-08-21 10:56 ` Eli Zaretskii
2010-08-21 12:51 ` Uday S Reddy
2010-08-21 13:02 ` Jan Djärv
2010-08-21 15:36 ` Eli Zaretskii
2010-08-22 7:39 ` Stephen J. Turnbull
2010-08-21 17:10 ` Stephen J. Turnbull
2010-08-21 9:03 ` Eli Zaretskii
2010-08-21 12:31 ` Uday S Reddy
2010-08-21 13:45 ` Óscar Fuentes
2010-08-21 14:56 ` Uday S Reddy
2010-08-21 17:32 ` Óscar Fuentes
2010-08-22 7:45 ` Stephen J. Turnbull
2010-08-21 15:48 ` Eli Zaretskii
2010-08-21 19:10 ` Stephen J. Turnbull
2010-08-21 18:59 ` Stephen J. Turnbull [this message]
2010-08-21 19:50 ` Leo
2010-08-21 19:59 ` Eli Zaretskii
2010-08-21 20:17 ` Leo
2010-08-21 20:31 ` Leo
2010-08-22 1:41 ` Tom Tromey
2010-08-22 1:47 ` Leo
2010-08-22 13:47 ` David De La Harpe Golden
2010-08-22 13:53 ` Andreas Schwab
2010-08-22 6:52 ` Stephen J. Turnbull
2010-08-22 7:56 ` Eli Zaretskii
2010-08-22 8:28 ` Stephen J. Turnbull
2010-08-22 8:57 ` Leo
2010-08-22 15:11 ` Eli Zaretskii
2010-08-21 19:56 ` Eli Zaretskii
2010-08-21 21:51 ` Uday S Reddy
2010-08-21 22:38 ` Stefan Monnier
2010-08-22 9:03 ` Uday S Reddy
2010-08-22 9:36 ` Teemu Likonen
2010-08-22 9:44 ` Eli Zaretskii
2010-08-22 11:25 ` Stephen J. Turnbull
2010-08-23 4:24 ` Richard Stallman
2010-08-23 4:54 ` Eli Zaretskii
2010-08-23 7:52 ` Glenn Morris
2010-08-23 13:55 ` Eli Zaretskii
2010-08-24 4:32 ` Richard Stallman
2010-08-24 13:30 ` Karl Fogel
2010-08-24 4:32 ` Richard Stallman
2010-08-23 9:55 ` Stephen J. Turnbull
2010-08-23 4:24 ` Richard Stallman
2010-08-23 5:06 ` Eli Zaretskii
2010-08-23 7:58 ` Uday S Reddy
2010-08-23 10:31 ` Stephen J. Turnbull
2010-08-23 12:41 ` Uday S Reddy
2010-08-24 6:31 ` Stephen J. Turnbull
2010-08-24 12:37 ` Lluís
2010-08-24 13:05 ` Lluís
2010-08-24 13:25 ` Óscar Fuentes
2010-08-24 14:18 ` Stephen J. Turnbull
2010-08-24 15:25 ` Lluís
2010-08-24 14:10 ` Stephen J. Turnbull
2010-08-24 15:02 ` Lluís
2010-08-24 16:59 ` Eli Zaretskii
2010-08-24 21:27 ` Óscar Fuentes
2010-08-24 16:42 ` Uday S Reddy
2010-08-24 17:12 ` Lluís
2010-08-24 18:47 ` Uday S Reddy
2010-08-24 14:05 ` Uday S Reddy
2010-08-24 15:54 ` Stephen J. Turnbull
2010-08-24 16:48 ` Eli Zaretskii
2010-08-25 13:03 ` Richard Stallman
2010-08-25 13:32 ` Juanma Barranquero
2010-08-31 21:33 ` Richard Stallman
2010-09-01 0:30 ` Chong Yidong
2010-09-01 1:44 ` Bernardo Barros
2010-09-01 2:36 ` Miles Bader
2010-09-01 3:07 ` Eli Zaretskii
2010-09-01 6:49 ` Stefan Monnier
2010-09-01 18:17 ` Richard Stallman
2010-09-01 19:10 ` Bastien
2010-09-02 5:22 ` Eli Zaretskii
2010-09-02 6:31 ` Bastien
2010-09-03 1:24 ` Richard Stallman
2010-09-03 8:01 ` Eli Zaretskii
2010-09-03 9:50 ` Bastien
2010-09-03 13:58 ` Karl Fogel
2010-08-25 20:25 ` Uday S Reddy
2010-08-27 15:36 ` Richard Stallman
2010-08-22 7:36 ` Stephen J. Turnbull
2010-08-22 8:52 ` Eli Zaretskii
2010-08-22 9:21 ` Stephen J. Turnbull
2010-08-22 9:38 ` Eli Zaretskii
2010-08-22 11:14 ` Stephen J. Turnbull
2010-08-22 11:47 ` Eli Zaretskii
2010-08-22 11:13 ` Jan Djärv
2010-08-22 13:13 ` Stephen J. Turnbull
2010-08-22 17:10 ` Jan Djärv
2010-08-21 2:29 ` Stephen J. Turnbull
2010-08-20 16:08 ` bzr smart server [was Re: Locks on the Bzr repository] Glenn Morris
2010-08-20 16:56 ` Lennart Borgman
2010-08-20 17:11 ` Eli Zaretskii
2010-08-20 17:13 ` Lennart Borgman
2010-08-20 17:23 ` Eli Zaretskii
2010-08-20 17:52 ` bzr smart server David Kastrup
2010-08-20 17:12 ` bzr smart server [was Re: Locks on the Bzr repository] Eli Zaretskii
2010-08-20 23:02 ` bzr smart server Stefan Monnier
2010-08-21 8:05 ` Eli Zaretskii
2010-08-21 13:22 ` Óscar Fuentes
2010-08-21 15:31 ` Eli Zaretskii
2010-08-21 17:09 ` Óscar Fuentes
2010-08-21 17:28 ` Eli Zaretskii
2010-08-21 13:46 ` Miles Bader
2010-08-21 15:32 ` Eli Zaretskii
2010-08-21 15:45 ` Miles Bader
2010-08-21 15:51 ` Eli Zaretskii
2010-08-21 17:16 ` Óscar Fuentes
2010-08-21 17:28 ` Jason Rumney
2010-08-21 17:36 ` Eli Zaretskii
2010-08-21 17:40 ` Óscar Fuentes
2010-08-21 14:00 ` Eric Hanchrow
2010-08-21 14:06 ` Lennart Borgman
2010-08-21 14:24 ` Óscar Fuentes
2010-08-21 15:12 ` Lennart Borgman
2010-08-21 17:12 ` Óscar Fuentes
2010-08-22 17:06 ` Richard Stallman
2010-08-20 4:44 ` Locks on the Bzr repository Miles Bader
2010-08-20 4:52 ` Jason Rumney
2010-08-20 6:22 ` Jan Djärv
2010-08-19 16:26 ` Eli Zaretskii
2010-08-19 16:54 ` Andreas Schwab
2010-08-19 16:12 ` Jason Rumney
2010-08-19 16:43 ` Dan Nicolaescu
2010-08-19 16:48 ` Jason Rumney
2010-08-19 17:08 ` Dan Nicolaescu
2010-08-19 17:32 ` Jason Rumney
2010-08-19 16:24 ` Eli Zaretskii
2010-08-19 17:29 ` Jason Rumney
2010-08-19 21:42 ` Stefan Monnier
2010-08-20 9:06 ` Eli Zaretskii
2010-08-21 9:37 ` Stefan Monnier
2010-08-19 16:26 ` Jay Belanger
2010-08-21 20:36 ` bzr send workflow (Was: Locks on the Bzr repository) Bojan Nikolic
2010-08-21 22:05 ` bzr send workflow Stefan Monnier
2010-08-21 22:48 ` Bojan Nikolic
2010-08-22 5:26 ` No ChangeLog's (was: bzr send workflow) Eli Zaretskii
2010-08-22 8:11 ` Stephen J. Turnbull
2010-08-22 8:58 ` Eli Zaretskii
2010-08-22 12:29 ` bzr send workflow Andreas Schwab
2010-08-22 13:14 ` Eli Zaretskii
2010-08-22 14:52 ` Andreas Schwab
2010-08-23 4:24 ` Richard Stallman
2010-08-23 5:11 ` Eli Zaretskii
2010-08-23 5:30 ` Eli Zaretskii
2010-08-24 4:32 ` Richard Stallman
2010-08-25 15:03 ` Andy Wingo
2010-08-25 19:18 ` Juanma Barranquero
2010-08-26 17:11 ` Chong Yidong
2010-08-26 17:26 ` Juanma Barranquero
2010-08-27 5:20 ` Stephen J. Turnbull
2010-08-27 11:27 ` Wojciech Meyer
2010-08-22 7:56 ` bzr send workflow (Was: Locks on the Bzr repository) Stephen J. Turnbull
2010-08-22 11:11 ` Lennart Borgman
2010-08-22 13:44 ` bzr send workflow Miles Bader
2010-08-22 14:40 ` Bojan Nikolic
2010-08-23 4:14 ` Stephen J. Turnbull
2010-08-23 5:33 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87vd737pxd.fsf@uwakimon.sk.tsukuba.ac.jp \
--to=stephen@xemacs.org \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=u.s.reddy@cs.bham.ac.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.