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 experimentCan it be transformed to
A --> B --> C mainline
\
\-> D --> E experimentwhen you realize that "experiment" is not ready for immediate merge? Or to
A --> B --> C mainline
\
\-> D --> E experimentif 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.