From: Eli Zaretskii <eliz@gnu.org>
To: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
Cc: emacs-devel@gnu.org
Subject: Re: Locks on the Bzr repository
Date: Sat, 21 Aug 2010 12:03:17 +0300 [thread overview]
Message-ID: <83aaogpcbu.fsf@gnu.org> (raw)
In-Reply-To: <i4n0au$g61$1@dough.gmane.org>
> From: Uday S Reddy <u.s.reddy@cs.bham.ac.uk>
> 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.
next prev parent reply other threads:[~2010-08-21 9:03 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 [this message]
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
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=83aaogpcbu.fsf@gnu.org \
--to=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.