[Mailman-Developers] Should we move to Bazaar?

[Stephen J. Turnbull]

Barry Warsaw writes:

 > On May 3, 2007, at 11:50 AM, Jon Scott Stevens wrote:

 > > #1. *everyone* knows how to use it and almost all OSS software
 > > projects use it.

You could say the same for Microsoft Windows.  But not for svk.  svk
apparently uses an idiosyncratic notation, not horrible or anything,
but not the same as svn either.

 > > #2. The subversion developers are *awesome*. I used to work with them
 > > at CollabNet and know them personally. Very smart great guys.

And (at least as of 8 months ago) still making no moves in the
direction of implementing lightweight branch and merge operations.

 > > #3. SVK solves the problems that you are talking about.

Does it?  I browsed the svk site trying to find something like Martin
Poole's design notes for bzr or hg's design whitepaper or git(7) or
Darc's Theory of Patches appendix.  Most of the stuff that would be
relevant to the problems Barry describes comes under links that point
to empty or nonexistent pages. :-(

The book apparently has not been worked on since mid-November.
http://svkbook.elixus.org/nightly/en/svk-book.html

If the documentation is any indication, svk cannot be considered
mature.

The article at perl.com is useful overview though:
http://www.perl.com/pub/a/2004/03/03/svk.html.

 > > #4. It would allow you to host your source code on code.google.com
 > > for free and be able to have the benefits of taking advantage of
 > > google's infrastructure.

 > Does svk solve some of svn's problems?
 > 
 > - - The need to use svnmerge or similar tool so that revisions in  
 > different branches don't merge multiple times

svk claims to implement some of the advanced merges pioneered by Tom
Lord in Arch.  That would go a long way (the same algorithms are
implemented in bzr, of course).  However, choice of merge strategy in
Arch is a black art.

 > - - The need to sometimes commit changes before you're ready (i.e.  
 > double moves)
 > - - Inexplicable errors with cryptic error messages
 > - - Inability to merge across renames
 > - - True nested branches (svn:externals is broken).

 > share.  I'm skeptical that svk will substantially improve the  
 > development model over svn, but maybe I'm just guilty of a greener  
 > pastures mentality.

You'd need somebody who uses it heavily to say.  But the home page
talks the talk; it could be equivalent to bzr on that front (up to a
point; the theory on that wiki is all by reference to Tom Lord and
Martin Poole and David Roundy).  Does it walk the walk?

I also don't see a lot about how to use svk in a distributed project.
It seems like the author is normally the only user of his
repositories; he just didn't want to be tied to a central server.
(That's probably not true, but the documentation reads that way.)

And, dare I mention that svk is a Perl application?<wink>

 > >> Branches in Bazaar are cheap, unlike in Subversion.
 > >
 > > I'm really sorry Barry, but that's just plain untrue. Read this:
 > >
 > > http://svnbook.red-bean.com/en/1.0/ch04s02.html
 > > "Cheap Copies"
 > 
 > It's not the same thing.  svn cp is pretty heavyweight compared to  
 > bzr branch.  To have an svn branch revision controlled it has to be  
 > committed back to the server and that's what makes it so heavy.  With  
 > bzr (and I'm assuming hg), you can branch locally 'til the cows come  
 > home,

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

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

To be honest, since I don't know svk, I can't deprecate it as an app.
I don't see any indication that it's an improvement over bzr or hg.
OTOH, the documentation is poor compared to bzr or hg.  Bottom line:
if you can find a champion for it, who will go the distance to support
Mailman using it, it might be a choice worth considering.  But without
a champion, no need to go out of your way IMO.