[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] What does code_copy_enabled do?

From: Andreas Färber
Subject: Re: [Qemu-devel] What does code_copy_enabled do?
Date: Tue, 12 Feb 2008 13:06:02 +0100


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

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]