Re: Switching to Subversion

[Stefan Monnier]

>> - Subversion has had more hours (and manhours) devoted to it than the sum of
>> its competitors, yet it still lacks the most commonly needed tool
>> (besides what CVS already offers): merge support.

> Doing it right is hard, and probably couldn't be really made in
> a back-compatible way. I'd expect that for 2.0. And, to be fair, that time
> has been spent in other ways: alternative backends, three repository
> access methods, WebDAV/DeltaV, good bindings for third-party tools (look
> at SVK :), localization, *excellent* documentation, and it is generally
> rock-solid.

All I really need from a successor to CVS:
- one backend that works well enough.
- same access methods as CVS (i.e. ssh/sftp and anonymous).
- good support for batch-processing (neat bindings via dlls is of no use for
  Emacs).  Localization can even get in the way here.
- support for merge.
- support for file rename.

The first 3 are what CVS already provides.  Svn only added the last point
and forgot the penultimate (even though it's a lot more important in my
experience).

Yes, SVN's doc is good.  But I can't help feel very uncomfortable with
a project that took so much time on side things and buzzwords and forgot the
core "branch merge" operation.

> As I've said several times, what SVN has is much more maturity; that's
> where the manhours have been spent.

Not quite true: manhours have also been spent in large part on the lack of
a clean and simple basic design.  Simplicity has never really been serious
design considerations (at least not at the beginning, when it mattered).
The contrast with something like DaRCS, Arch, ..., is truly striking.

>> - Subversion is a big and heavy piece of software, which I'm not very eager
>> to have to rely on.
> Well, I prefer that to requiring Python or Perl or Haskell (which I
> love) or whatnot.

[ I really don't want to go there. ]
Haskell (and Python and Perl to a lesser degree) are much more reliable
languages than C, with whole classes of bugs (some of which are among the
most notorious security holes) ruled out by the language itself.

> I don't have anything against other tools, of course, if they have
> native implementations in Windows and the interface is reasonably fast
> (assuming the underlying design is sound :)

Yes, Arch is out, sadly.  It doesn't support Windows well enough, and its
speed is terrible under Mac OS X (apparently because HFS+ handles hardlinks
pessimally).


        Stefan