Re: Proposal: Subversion Migration

[MJ Ray]

Roland Schwingel <roland.schwingel@onevision.de> wrote:
> MJ Ray wrote:
>  > The drawbacks of SVN remain:
>  > * non-distributed (same as CVS)
> Is this really needed?

Are any of the features really needed? No, but they're all nice.

>  > * incompatible with the git-using tools (same as CVS)
> Is this a drawback? [...]

Yes. It will make it more painful to migrate again.

>  > * poor library licence limits integration
> You don't need to program against it. [...]

We don't *need* to migrate to it either. Need is not the question.

>  > * client at least fivefold more disk, probably bigger in memory too
> ??? A subversion working copy is bigger then the CVS one, thats true.
> But not more than twice! How do you come to that number? [...]

Base debian testing maching, select cvs in aptitude, note amount
of extra space required. Clear the selection. Select subversion
in aptitude, note amount of extra space required.

I didn't know about the working copies being bigger too. Isn't
that another drawback?

>  > * reconfigure everything now, only to move again soon
> I don't think you need to move again after going to svn.

There are features that are missing from svn and past interactions
between svn developers and other version control developers make
me think that they won't be part of svn core any time soon.

> [...] SVN is absolutely reliable and fast [...]

I think you just painted yourself as a SVN fanatic. Why was the
fsfs backend added if SVN is absolutely reliable and fast since
two years ago?

> - excellent documentation (free SVN book)

Actually, the SVN book is non-free, but that's minor.

It's not "why does SVN beat CVS" - beating CVS in many ways should
be fairly easy and it's a real black mark that SVN is worse than
CVS in the few ways that it is. It's "why does SVN beat the other
modern version controls, and CVS by enough to move today?"