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

[Andreas Färber]

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