[Mailman-Developers] Should we move to Bazaar?

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On May 4, 2007, at 3:57 PM, Stephen J. Turnbull wrote:

> That's right.  In my integration workspace maintained under git, I
> basically branch for *every* commit back to the XEmacs CVS, and delete
> the branch when I see the commit notice.  In my sandbox, I have about
> 75 branches.  I branch for reviewing others' patches, I branch for
> typo fixes that can be pushed to mainline immediately.  I switch
> branches when I fix typos while working on larger tasks, then switch
> back and pull the typo.

I do the same thing.  It's really a fundamentally different way to  
think about developing software, IME.  Since CVS we're so conditioned  
to the weight of branches that this is a really liberating  
enlightenment.

> I cannot imagine doing that in CVS or Subversion, nor have I yet seen
> a ViewCVS of an svn repo that looks like that.  But Arch (tla or bzr),
> git, and hg repos all have more branches than a centipede has legs, at
> least for active projects.  It's possible that svk could support that
> style, though, since it is decentralized.
>
> The other question about svn/svk is does it have a rebase operation?
> ("Rebase" is from git; it's called "tla update" in Arch, probably the
> same in bzr, "patch commutation" in Darcs.)  That is, suppose you have
> a revision graph
>
>          A --> B --> C  mainline
>           \
>            \-> D --> E  experiment
>
> Can it be transformed to
>
>          A --> B --> C              mainline
>                       \
>                        \-> D --> E  experiment
>
> when you realize that "experiment" is not ready for immediate merge?
> Or to
>
>          A --> B --> C        mainline
>                 \
>                  \-> D --> E  experiment
>
> if you know that E conflicts with C (either textually, or because
> they're different ways to implement the same change)?

I've not needed to do this yet, but I can see where it would be a  
very useful feature to have.  Here's what the www.bazaar-vcs.org  
pages have to say about it.

 From http://bazaar-vcs.org/ShowStoppers/Samba

A rebase plugin would be very nice, with a rebase-push command. It  
should be used in combination with bound branches. The rebase-push  
command should try to rollback local commits, then pull all new  
revisions from the master branch and recommit to the master branch  
one by one. And then pull the new commits back to the local branch.  
Maybe a rebase-pull command would do the same but not directly push  
the local changes, but instead recommit locally. This features seems  
to be related to patch reordering, patch refactoring and a bzr sync- 
trees command. See also http://www.kernel.org/pub/software/scm/git/ 
docs/git-rebase.html. The rebase feature should be only used on  
integration branches with unrelated patches, so that they don't  
appear as one big merge revision in the master branch. For feature  
specific branches normal 'merge --pull' and a final 'push' should be  
used.

> That's really a more important operation to distributed development
> than starmerge (unless you're Linus), because it is the fundamental
> operation for non-core developers producing the occasional patch or
> perhaps a single, long-lived variant (think Richard Barrett's MHonArc
> patch).

I do something similar all the time, but generally what I do is  
branch a local "pristine" branch off the mainline branch, then all my  
dev branches are branches off of pristine.  When I need to pull the  
mainline into a dev branch, I 'bzr pull' the pristine branch to get  
the tip of mainline, then I merge & commit in any dev branch that I  
want to rebase to the tip.  I've not needed to rebase to anything  
other than the tip (though I do occasionally have to resolve  
conflicts of course), but I could imagine that'd be doable by  
manually specifying a revision to branch from.

- -Barry


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)

iQCVAwUBRjurhXEjvBPtnXfVAQKpWQP/ctmR9pNJqCj4vRJ9jWNltPVvvBpnpUqf
Sc0FWtGa3KYdgxsGIMmhXtcusfmUOcu7oeoaFsU3GG3npDbDi6p6SOy5XajjWOla
2DMDNwD7FJTZOW4kKx6ghF7YDDdm1LfMJlGJi6NMQX5h0W++WAOTYrqEOy/rXej4
tC8ff0hKLyo=
=Rx3Z
-----END PGP SIGNATURE-----