Hi,
Am 12.02.2008 um 12:15 schrieb Johannes Schindelin:
On Tue, 12 Feb 2008, Paul Brook wrote:
Any news on the possible cvs->svn migration?
To be perfectly honest, IMO there is little point moving an existing
project from CVS to SVN.
I disagree. CVS has several fairly fundamental flaws (no global
revision IDs, unable to move files, and more subtle problems with
branches/tags). SVN fixes these, and in most cases works as a direct
drop-in replacement for CVS.
Granted, SVN is better than CVS. But they did not even begin to
tackle
the fundamental shortcomings.
While I can see that distributed revision control systems do enable
some
interesting possibilities, there's certainly no clear winner.
There might not be a clear winner, but that's only because they are
about equally "good". Using this argument to choose an inferiour
system,
such as svn, which is not only slower, bigger, has a lousy
tagging/annotating/merging support, but actively discourages good
workflows, is, uhm, not so wise.
Currently SVN is much more widely supported than Git, which seem to be
the only two alternative options here at Savannah.
All of them seem to have have fairly serious issues with either
usability, portability, scalability, and/or require learning a
whole new
workflow.
Note that he said 'either'.
Usability: uhm, no. There are enough short tutorials to show that
Hg and
Git are pretty easy to learn.
Portability: uhm, no. Hg never had an issue there, Git no longer
does.
Mercurial has a hard dependency on Python; Git only an optional
dependency on Tcl/Tk for their GUI. SVN tarballs don't need either
(only SVN from SVN needs Perl+Python).
Whole new workflow: uhm, no. You do not _need_ to use the bells and
whistles of Hg or Git, if you really are that resistant.
Johannes, just navigating around your Git repository is "hard" for
someone not comfortable with git. The git pull etc. part is easy
compared to that. The Subversion URLs make it much more obvious to
find branches; something that's really missing in our CVS and recently
forced to fork a stable branch elsewhere.
But if you have 5 options, 2 of them just shine, and the other 3 are
bad,
do you really pick a bad apple, because "there is no best"?
This is pointless and untrue. I agree with Paul that SVN is better
than CVS and so did you above; so there's no black-and-white or 2:3
really.
And may I add that for SVN there's apparently also an SVK in addition
to the already mentioned git/hg interoperability. (haven't used it
personally though)
The really interesting question I see is whether a move from CVS to
SVN here at Savannah would allow the CVS history to be imported using
said heuristics. If no, then I assume it's out of the question anyway.
Andreas
