Re: Switching to Subversion

[Juanma Barranquero]

On 11/13/06, Stefan Monnier <address@hidden> wrote:

> Basically Subversion's been UI-driven, with fundamental
> features retrofitted afterwards.  That is a design methodology which
> doesn't always result in the cleanest and most robust result.

In my opinion (and I'm just a lurker on Subversion), that's not
entirely true. On one hand, yes, it was a  bit UI-driven because its
stated goal was to be "a better CVS". But on the other hand, some
things are just the result of decisions that seemed good at the time:
for example, not having true renames, or using branches for tagging.

> - 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. As I've said several
times, what SVN has is much more maturity; that's where the manhours
have been spent.

> - 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. And certainly SCMs whose interface is made of
scripts don't strike me as very serious (call me prejudiced).

> So I'd rather use Arch, DaRCS, Mercurial, GIT, you name it.

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

                   /L/e/k/t/u