Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Blue Swirl]

On 2/8/08, Rob Landley <rob@landley.net> wrote:
> On Thursday 07 February 2008 21:52:33 Paul Brook wrote:
> > On Friday 08 February 2008, Rob Landley wrote:
> > > Grepping through the source code, I can find 3 places where this global
> > > variable is set (it's initialized to a default value of 1, there's
> > > a "no-code-copy" command line option that sets it to zero, and then it
> > > shows up in the test suite once).  What I can't find is any code ever
> > > actually checking or using the value put into this variable....
> >
> > It got ripped out a while back.
>
> Any news on the possible cvs->svn migration?  I'd submit a cleanup patch to
> rip out the remaining traces of code_copy_enabled, but the git mirror I
> follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days
> so I'm not actually sure it's still there in cvs.
>
> Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there
> either...

How about git? I'd like to use git bisect. Would there be problems if
it were possible to commit via more than one interface?

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Blue Swirl wrote:

> On 2/8/08, Rob Landley <rob@landley.net> wrote:
> > On Thursday 07 February 2008 21:52:33 Paul Brook wrote:
> > > On Friday 08 February 2008, Rob Landley wrote:
> > > > Grepping through the source code, I can find 3 places where this global
> > > > variable is set (it's initialized to a default value of 1, there's
> > > > a "no-code-copy" command line option that sets it to zero, and then it
> > > > shows up in the test suite once).  What I can't find is any code ever
> > > > actually checking or using the value put into this variable....
> > >
> > > It got ripped out a while back.
> >
> > Any news on the possible cvs->svn migration?  I'd submit a cleanup 
> > patch to rip out the remaining traces of code_copy_enabled, but the 
> > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't 
> > updated in several days so I'm not actually sure it's still there in 
> > cvs.
> >
> > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't 
> > there either...
> 
> How about git? I'd like to use git bisect. Would there be problems if it 
> were possible to commit via more than one interface?

You mean using nongnu.org's git support?  And the cvsserver 
emulation, so that CVS people can still access it via CVS?  That's an 
option, but I do not know if nongnu.org has enabled cvsserver emulation.

And I'm not a fan of _forcing_ people to switch to another SCM.  You can 
use git (and even cvsimport yourself, should the public git mirrors lag), 
and even svn, as pbrook showed, even if the official upstream stays CVS.

Ciao,
Dscho

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Blue Swirl]

On 2/9/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Sat, 9 Feb 2008, Blue Swirl wrote:
>
> > On 2/8/08, Rob Landley <rob@landley.net> wrote:
> > > On Thursday 07 February 2008 21:52:33 Paul Brook wrote:
> > > > On Friday 08 February 2008, Rob Landley wrote:
> > > > > Grepping through the source code, I can find 3 places where this global
> > > > > variable is set (it's initialized to a default value of 1, there's
> > > > > a "no-code-copy" command line option that sets it to zero, and then it
> > > > > shows up in the test suite once).  What I can't find is any code ever
> > > > > actually checking or using the value put into this variable....
> > > >
> > > > It got ripped out a while back.
> > >
> > > Any news on the possible cvs->svn migration?  I'd submit a cleanup
> > > patch to rip out the remaining traces of code_copy_enabled, but the
> > > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't
> > > updated in several days so I'm not actually sure it's still there in
> > > cvs.
> > >
> > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't
> > > there either...
> >
> > How about git? I'd like to use git bisect. Would there be problems if it
> > were possible to commit via more than one interface?
>
> You mean using nongnu.org's git support?  And the cvsserver
> emulation, so that CVS people can still access it via CVS?  That's an
> option, but I do not know if nongnu.org has enabled cvsserver emulation.

Something like that. :-)

> And I'm not a fan of _forcing_ people to switch to another SCM.  You can
> use git (and even cvsimport yourself, should the public git mirrors lag),
> and even svn, as pbrook showed, even if the official upstream stays CVS.

I'm not suggesting a forced switch either, that's why I was asking if
it's possible to have R/W access enabled for several SCMs at once.

I'm also still learning git, can I completely replace CVS access by
using cvsimport and cvsexportcommit locally?

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Blue Swirl wrote:

> On 2/9/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > And I'm not a fan of _forcing_ people to switch to another SCM.  You 
> > can use git (and even cvsimport yourself, should the public git 
> > mirrors lag), and even svn, as pbrook showed, even if the official 
> > upstream stays CVS.
> 
> I'm not suggesting a forced switch either, that's why I was asking if 
> it's possible to have R/W access enabled for several SCMs at once.

That's tricky.  You can mirror, of course, but that is prone to 
desynchronisation.  But as I said, git has a cvs emulator.

> I'm also still learning git, can I completely replace CVS access by 
> using cvsimport and cvsexportcommit locally?

I do that in two projects, so yes, you can do that.  cvsexportcommit is a 
little tricky, especially when you do not want to have an extra working 
directory for CVS.

So this is what I do regularly:

$ git --git-dir=$(pwd)/.git cvsexportcommit -c -p -u master^ master

The "-c" means to really commit when the patch applies, "-p" means to 
check anally that the patch applies, the "-u" means that it tries to 
cvs update the files to the correct version first.

I need to checkout the "origin" branch for that to work, though (I've 
been meaning to work on cvsexportcommit, but time is really scarce).

Ciao,
Dscho

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Felipe Contreras]

On Feb 9, 2008 2:45 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
>
> On Sat, 9 Feb 2008, Blue Swirl wrote:
>
> > On 2/8/08, Rob Landley <rob@landley.net> wrote:
> > > On Thursday 07 February 2008 21:52:33 Paul Brook wrote:
> > > > On Friday 08 February 2008, Rob Landley wrote:
> > > > > Grepping through the source code, I can find 3 places where this global
> > > > > variable is set (it's initialized to a default value of 1, there's
> > > > > a "no-code-copy" command line option that sets it to zero, and then it
> > > > > shows up in the test suite once).  What I can't find is any code ever
> > > > > actually checking or using the value put into this variable....
> > > >
> > > > It got ripped out a while back.
> > >
> > > Any news on the possible cvs->svn migration?  I'd submit a cleanup
> > > patch to rip out the remaining traces of code_copy_enabled, but the
> > > git mirror I follow (git://git.kernel.dk/data/git/qemu.git) hasn't
> > > updated in several days so I'm not actually sure it's still there in
> > > cvs.
> > >
> > > Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't
> > > there either...
> >
> > How about git? I'd like to use git bisect. Would there be problems if it
> > were possible to commit via more than one interface?
>
> You mean using nongnu.org's git support?  And the cvsserver
> emulation, so that CVS people can still access it via CVS?  That's an
> option, but I do not know if nongnu.org has enabled cvsserver emulation.
>
> And I'm not a fan of _forcing_ people to switch to another SCM.  You can
> use git (and even cvsimport yourself, should the public git mirrors lag),
> and even svn, as pbrook showed, even if the official upstream stays CVS.

Anything but CVS please.

SVN is a good option, then people can use their favorite dscm
(git-svn, bzr-svn, etc).

Right now I can't use qemu because a bug introduced in the last months
and with git-bisect I probably would be able to fix it myself.

Best regards.

-- 
Felipe Contreras

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Johannes Schindelin]

Hi,

On Sat, 9 Feb 2008, Felipe Contreras wrote:

> Right now I can't use qemu because a bug introduced in the last months 
> and with git-bisect I probably would be able to fix it myself.

Just clone git://repo.or.cz/qemu.git, then.

Hth,
Dscho

[Qemu-devel] What does code_copy_enabled do?

[Rob Landley]

Grepping through the source code, I can find 3 places where this global 
variable is set (it's initialized to a default value of 1, there's 
a "no-code-copy" command line option that sets it to zero, and then it shows 
up in the test suite once).  What I can't find is any code ever actually 
checking or using the value put into this variable....

What's it for?

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

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

[Paul Brook]

On Friday 08 February 2008, Rob Landley wrote:
> Grepping through the source code, I can find 3 places where this global
> variable is set (it's initialized to a default value of 1, there's
> a "no-code-copy" command line option that sets it to zero, and then it
> shows up in the test suite once).  What I can't find is any code ever
> actually checking or using the value put into this variable....

It got ripped out a while back.

Paul

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

[Rob Landley]

On Thursday 07 February 2008 21:52:33 Paul Brook wrote:
> On Friday 08 February 2008, Rob Landley wrote:
> > Grepping through the source code, I can find 3 places where this global
> > variable is set (it's initialized to a default value of 1, there's
> > a "no-code-copy" command line option that sets it to zero, and then it
> > shows up in the test suite once).  What I can't find is any code ever
> > actually checking or using the value put into this variable....
>
> It got ripped out a while back.

Any news on the possible cvs->svn migration?  I'd submit a cleanup patch to 
rip out the remaining traces of code_copy_enabled, but the git mirror I 
follow (git://git.kernel.dk/data/git/qemu.git) hasn't updated in several days 
so I'm not actually sure it's still there in cvs.

Just checked and http://savannah.nongnu.org/svn/?group=qemu isn't there 
either...

> Paul

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

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

[Ian Jackson]

Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?"):
> Just clone git://repo.or.cz/qemu.git, then.

Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...

Ideally it would be good for those of us who don't like CVS, and who
want to be a bit more profligate with accepting patches, to be able to
pull from each others' trees.

As I understand it that really means at the very least that there
ought to be one official git tree mirrored from CVS.

I assume that all of these mirrors are made using git-cvsimport in the
most usual way ?  The associated websites are a bit sparse.  It would
be nicer, if we were going to have something to base our work on, to
have a repository which is updated by cron and publicly available.

I'd be happy to either use an existing mirror or to set one up.

Ian.

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

[Johannes Schindelin]

Hi,

On Mon, 11 Feb 2008, Ian Jackson wrote:

> Johannes Schindelin writes ("Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?"):
> > Just clone git://repo.or.cz/qemu.git, then.
> 
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > ... the git mirror I follow (git://git.kernel.dk/data/git/qemu.git) ...

Now, that is funny.  You quote me, and you quote Rob, but culled both of 
us from the Cc list.

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

[Ian Jackson]

Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> Now, that is funny.  You quote me, and you quote Rob, but culled both of 
> us from the Cc list.

How strange.  I definitely didn't mean to do that, sorry.

...tests...

This is the fault of the Reply-To munging.

Ian.

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

[Ian Jackson]

Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> 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.  SVN has better support for renames, and a
few other advantages, but branching is still pretty catastrophic.

Any of the currently popular drcs's would be a big improvement.  In
particular it would make it much easier to do development on changes
that don't want to go in CVS mainline for any reason.

Ian.

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

[Felipe Contreras]

On Feb 11, 2008 5:52 PM, Ian Jackson <Ian.Jackson@eu.citrix.com> wrote:
> Rob Landley writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > 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.  SVN has better support for renames, and a
> few other advantages, but branching is still pretty catastrophic.
>
> Any of the currently popular drcs's would be a big improvement.  In
> particular it would make it much easier to do development on changes
> that don't want to go in CVS mainline for any reason.

The advantage of using SVN is that most drcs play along with it quite
decently. Something that doesn't happen with CVS.

-- 
Felipe Contreras

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

[Johannes Schindelin]

Hi,

On Mon, 11 Feb 2008, Felipe Contreras wrote:

> The advantage of using SVN is that most drcs play along with it quite 
> decently. Something that doesn't happen with CVS.

So you're saying in order to use a DVCS you would need to switch to a 
CVCS?

Puzzled,
Dscho

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

[Rob Landley]

On Monday 11 February 2008 14:38:42 Johannes Schindelin wrote:
> Hi,
>
> On Mon, 11 Feb 2008, Felipe Contreras wrote:
> > The advantage of using SVN is that most drcs play along with it quite
> > decently. Something that doesn't happen with CVS.
>
> So you're saying in order to use a DVCS you would need to switch to a
> CVCS?

No, you need to switch _off_ of CVS.

CVS hasn't got the concept of "changesets".  You can treat a real CVCS as a 
DVCS that' s never branched, just a linear series of changesets with no merge 
nodes.  But CVS _isn't_ a real CVCS.  It's not a series of changesets, it's a 
bunch of separately tracked files.

You know how a single patch can touch a dozen different files?  CVS doesn't 
understand that.  Its dumber than the "patch" program.  In CVS, every single 
file stands alone, its history unrelated to any of the others.  Out of sheer 
self-preservation, most CVS users check in changes to lots of different files 
at once, with identical comments, so you can go back later and match changes 
up by timestamp and check that the comments match.  But this is just a 
heuristic, dependent on the behavior of the users, and it only sort of works 
at the best of times because unless your CVS server is infinitely fast, the 
timestamps won't be _identical_ but just _close_.  How close is close enough?  
Don't go there.  (I tried to write such a script once.  It hurt.)

But having to do data mining in order to detect changesets is an evil 
specialized black art, it breaks easily, and generally you want to convert up 
to at least something that understands changesets and NEVER LOOK BACK.

> Puzzled,
> Dscho

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

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

[Felipe Contreras]

On Feb 11, 2008 10:38 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Mon, 11 Feb 2008, Felipe Contreras wrote:
>
> > The advantage of using SVN is that most drcs play along with it quite
> > decently. Something that doesn't happen with CVS.
>
> So you're saying in order to use a DVCS you would need to switch to a
> CVCS?

I'm saying * > CVS. Even SVN would be fine.

BTW, I found the issue, it's on "linux-user/mmap.c" :)

-- 
Felipe Contreras

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

[Paul Brook]

> > 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.

While I can see that distributed revision control systems do enable some 
interesting possibilities, there's certainly no clear winner.  All of them 
seem to have have fairly serious issues with either usability, portability, 
scalability, and/or require learning a whole new workflow.  I'm sure 
advocates of each system will claim that their system is the "best", but I 
remain unconvinced.

SVN may not have the bells and whistles of some of the more exotic systems. 
However it is is well tested proven technology, and IMO universally better 
than CVS.

Paul

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

[M. Warner Losh]

In message: <200802120232.22591.paul@codesourcery.com>
            Paul Brook <paul@codesourcery.com> writes:
: > > 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.

FreeBSD is moving from CVS to SVN for these reasons.

: While I can see that distributed revision control systems do enable some 
: interesting possibilities, there's certainly no clear winner.  All of them 
: seem to have have fairly serious issues with either usability, portability, 
: scalability, and/or require learning a whole new workflow.  I'm sure 
: advocates of each system will claim that their system is the "best", but I 
: remain unconvinced.

Well, svn now has svn to hg and svn to git gateways, so really it
caters to all comers...

Warner

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

[Julian Seward]

> : > > 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.
>
> FreeBSD is moving from CVS to SVN for these reasons.

Just to second "M. Warner Losh": we moved Valgrind from CVS to SVN about
3.5 years ago and it was an excellent thing to do.  It is not true to say
there is no advantage over CVS -- the global revision IDs, the ability to
rename files, and a simpler branching/tagging model are all big advantages.
And the fact that it is more-or-less conceptually a drop-in replacement makes
it easy for people to make the migration.

Sure, Valgrind is a tiny project compared to FreeBSD.  But we gain those
advantages nonetheless.

J

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

[Johannes Schindelin]

Hi,

I did not really want to continue this discussion, but then, I really 
cannot let certain statements slip by.  *sigh*

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.

> All of them seem to have have fairly serious issues with either 
> usability, portability, scalability, and/or require learning a whole new 
> workflow.

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.

Scalability: I do beg your pardon?  Hg might not be as scalable as Git, 
but SVN and CVS positively *suck* in that respect.

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.

You can just update & add & commit as before (with Git, you just need to 
substitute "pull" for "update").  The only difference is that you push to 
the "official" server from time to time.

> I'm sure advocates of each system will claim that their system is the 
> "best", but I remain unconvinced.

I'm sure you remain unconvinced, if only to make a point.  As for "best": 
I would not claim that either Hg or Git are "best".  My preference is 
clear.

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"?

> SVN may not have the bells and whistles of some of the more exotic 
> systems. However it is is well tested proven technology, and IMO 
> universally better than CVS.

It is well tested and proven, granted.  As a version control system.  But 
in terms of a source code management tool, it just leaves to be desired.

Ciao,
Dscho

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

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

[Ian Jackson]

It seems to me that there are two questions here:

 * Should the CVS for the upstream repository be replaced with
   something else ?
 * In the meantime, or if upstream decide not to, what is the best way
   for non-upstream contributors to collaborate with each other ?


The answer to the first question is unambiguously `yes', I think.

There are approximately five serious contenders for the replacement:
svn, darcs, hg, git, bzr.  Switching now to any of the drcs's would be
unlikely to be regretted in the medium to long term.

I haven't used darcs, but I'm in a perhaps slightly unusual position
of having used all of hg, git, bzr and cvs.  (I've touched svn too but
haven't done anything at all complicated with it, like branching.)

I think that for cvs refugees, the right answer is bzr. [1][2]
bzr is strictly better than cvs in almost every respect.

In particular, refugees from cvs and svn will find it easy to get to
grips with.  To a large extent you can just say `bzr whatever' instead
of `cvs whatever', confident that it will do the right thing - and
guessing is safe because even if that was the wrong rune it generally
won't do something crazy and make a hideous mess.

The areas where bzr is comparatively weak (performance, advanced forms
of merging, lightweight branching, etc.) are already worse in cvs.

On the other hand, git's and hg's weaknesses are clear regressions
from cvs.  git's user interface is frankly appalling.  It's very
functional and some day I hope to see a wrapper which makes git look
more like the way everyone expects an rcs to work, and avoids blowing
off one's leg.  In the meantime I do use it myself but I'm wary of
pushing it.

hg is much better.  OTOH it does have one severe problem: it expects
you to check in before merging, which is the opposite of what cvs
users expect.  A cvs refugee, or anyone working on a project whose
leaders don't like merge changesets (yes, they exist) will notice new
changes upstream and decide to merge them into their current tree with
`hg pull -u', which is the equivalent of `cvs update'.  However, that
rune's handling of merge conflicts is catastrophically bad and likely
to lead to the working tree being effectively destroyed, possibly
losing a great deal of work.


As I've said, I think there is no point switching from cvs to svn.
It's true that cvs's lack of the concept of a changeset is a serious
problem and makes mirroring a cvs repository something of a challenge.
However, there is already software to reconstruct changesets from cvs
logs, and provided the cvs users use cvs in a sane and predictable way
(which current qemu upstream do) those conversion tools do work.

svn's support for branches is even worse than that of cvs's; this is
frankly astonishing given how painful branches are to work with in cvs
and how long this has been known to be a serious problem.

But really my point is that change is painful so if we're going to try
to switch to a new revision control system, with all of the learning,
messing about with new software, cursing, and so on, we should try to
get as much benefit as we can for our effort.

Anyone who switches to svn now will, I think, regret it in another few
years.  The pressure to switch to a drcs will not go away.


On to the second question:

What should those of us who want to collaborate using a drcs (so that
we can share our work-in-progress patches and generally avoid blocking
on upstream) do in the meantime ?

Having a private mirror of a drcs is all well and good but no-one can
pull from anyone else because each cvs/svn->drcs conversion yields an
incompatible history.

At the very least we need one drcs branch containing only changes from
the upstream cvs.  It has to be incrementally updated, automatically
and frequently, and generally be well maintained.

Most of the potential users seem to be fans of git which is fine by
me.  If there is someone who knows git better than me and would like
to provide a properly supported regularly updated git mirror of the
upstream cvs then I would be happy to use and pull from it.

Otherwise I would be quite happy to maintain such a thing on
www.xen.org (the website for the Open Source Xen).

Ian.
(I hope the Reply-To munging hasn't caused anyone to be dropped from
the CC; I've done a quick check but please forgive me if I missed one.)

[1] Full disclosure: Not everyone may be aware that I spent a couple
of years working for Canonical as an Ubuntu developer; I left in
November.  I didn't work on bzr.  IMO my recommendation of bzr is best
regarded as despite my relationship with Canonical, rather than
because of it.

[2] Some people think that bzr has some kind of dependency on
Launchpad.  This is not the case.  If it did I wouldn't be
recommending it.

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

[Johannes Schindelin]

Hi,

On Tue, 12 Feb 2008, Ian Jackson wrote:

>  * In the meantime, or if upstream decide not to, what is the best way
>    for non-upstream contributors to collaborate with each other ?
> 
> [...]
>
> What should those of us who want to collaborate using a drcs (so that we 
> can share our work-in-progress patches and generally avoid blocking on 
> upstream) do in the meantime ?
> 
> Having a private mirror of a drcs is all well and good but no-one can
> pull from anyone else because each cvs/svn->drcs conversion yields an
> incompatible history.
> 
> At the very least we need one drcs branch containing only changes from
> the upstream cvs.  It has to be incrementally updated, automatically
> and frequently, and generally be well maintained.

FWIW on this very list, there have been enough hints where you can find 
such a thing, and it is not even private.

Ciao,
Dscho

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

[Ian Jackson]

Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> On Tue, 12 Feb 2008, Ian Jackson wrote:
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs.  It has to be incrementally updated, automatically
> > and frequently, and generally be well maintained.
> 
> FWIW on this very list, there have been enough hints where you can find 
> such a thing, and it is not even private.

I've seen two people mention git mirror urls.

They contain different incompatible histories because they're
generated separately.  The problem isn't that we don't have a git
mirror of cvs.  The problem is that we need to have exactly _one_.

And if we're going to have exactly one then it has to be reliable.
That doesn't mean some mirror url found in a search engine.

It means a site whose operators we know, and whose operators have
shown some evidence of a commitment to keep it working, and whom we
can contact them if it breaks.  It means that the the update frequency
is published.  It means someone who has some connection with the qemu
community so that we can expect them to care about it.

If we have that then everyone can expect to pull from it and not
commit to a workflow that might suddenly become untenable.

Ian.

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

[Johannes Schindelin]

Hi,

On Tue, 12 Feb 2008, Ian Jackson wrote:

> Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> > On Tue, 12 Feb 2008, Ian Jackson wrote:
> > > At the very least we need one drcs branch containing only changes 
> > > from the upstream cvs.  It has to be incrementally updated, 
> > > automatically and frequently, and generally be well maintained.
> > 
> > FWIW on this very list, there have been enough hints where you can 
> > find such a thing, and it is not even private.
> 
> I've seen two people mention git mirror urls.
> 
> They contain different incompatible histories because they're
> generated separately.

If you mean the one at repo.or.cz and the one at kernel.dk, no.  They 
contain exactly the same history.

> The problem isn't that we don't have a git mirror of cvs.  The problem 
> is that we need to have exactly _one_.

I do not begin to understand why.

Ciao,
Dscho

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

[Ian Jackson]

Johannes Schindelin writes ("Re: [Qemu-devel] What does code_copy_enabled do?"):
> If you mean the one at repo.or.cz and the one at kernel.dk, no.  They 
> contain exactly the same history.

You're right.  I hadn't checked.  My own mirror generated with
git-cvsimport is incompatible with both of course, but those two are
in fact compatible.

How is that achieved ?  Is one of them a mirror of the other ?  Who
runs them ?  (Why do I have to asking about this on a mailing list
when there ought to be a web page telling me?)

Ian.

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

[Rob Landley]

On Tuesday 12 February 2008 05:57:18 Ian Jackson wrote:
> hg is much better.  OTOH it does have one severe problem: it expects
> you to check in before merging, which is the opposite of what cvs
> users expect.  A cvs refugee, or anyone working on a project whose
> leaders don't like merge changesets (yes, they exist) will notice new
> changes upstream and decide to merge them into their current tree with
> `hg pull -u', which is the equivalent of `cvs update'.

Notice how -u is an option, and the default is _not_ update your current 
working state?  If supplying an option has a behavior you don't like, which 
it won't do if you leave the option off, where's the problem?

(And one thing hg won't _ever_ do is throw <<<<<<< style crap into your source 
code when you pull, which you're implying is somehow desirable.)

> However, that 
> rune's handling of merge conflicts is catastrophically bad and likely
> to lead to the working tree being effectively destroyed, possibly
> losing a great deal of work.

This is a design issue.  Collisions happend during a merge, not during a 
checkin.  In a distributed source control system, a checkin always happens 
against a known state.  Therefore, if you do a pull from outside you're 
either doing an implicit merge (-u) or you're creating a new branch (if you 
do a checkin against an old version of the repository after pulling).

It's not really a user interface issue, it's a difference between how 
distributed and centralized source control systems work.

> As I've said, I think there is no point switching from cvs to svn.
> It's true that cvs's lack of the concept of a changeset is a serious
> problem and makes mirroring a cvs repository something of a challenge.
> However, there is already software to reconstruct changesets from cvs
> logs, and provided the cvs users use cvs in a sane and predictable way
> (which current qemu upstream do) those conversion tools do work.

Modulo being buggy and complicated.  But in theory they work, yes.  The 
current git mirrors are maintained from them, and I can limp along with that 
indefinitely.

> What should those of us who want to collaborate using a drcs (so that
> we can share our work-in-progress patches and generally avoid blocking
> on upstream) do in the meantime ?

Simple:

A) Pick a repository as your upstream.  Doesn't matter which, just as long as 
you agree.

or,

B) Send patches around ala cherry-pick, which is what you have to do to send 
them upstream anyway.

For the first 10 years Linus Torvalds's only source control system was the 
periodic release of tarball snapshots of his personal source tree.  Even CVS 
is only slightly worse than that.

> Having a private mirror of a drcs is all well and good but no-one can
> pull from anyone else because each cvs/svn->drcs conversion yields an
> incompatible history.

*shrug*  I'll live.

> At the very least we need one drcs branch containing only changes from
> the upstream cvs.  It has to be incrementally updated, automatically
> and frequently, and generally be well maintained.

Already exists.

> Most of the potential users seem to be fans of git which is fine by
> me.

No, most of the existing mirrors are git based, and the potential users are 
lazy enough to use what's in front of us.  I note that the most popular 
cvs->hg conversion tool (tailor) had a bug in it for most of last year, due 
to depending on a package (cvsps) that was broken in Ubuntu 7.04.

Mercurial itself had a new "convert extension" merged into mainline a few 
months ago, so it should now have cvs->hg functionality built in.  But it's 
brand new and I haven't fiddled with it yet.

Personally, I'd much rather have a mercurial repository, but I'm lazy enough 
to live with git if it's there.  It is considerably more complicated than 
mercurial, and has a horrible user interface, but it still means I don't have 
to deal with CVS directly.

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

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

[Felipe Contreras]

On Feb 13, 2008 10:22 AM, Rob Landley <rob@landley.net> wrote:
> On Tuesday 12 February 2008 05:57:18 Ian Jackson wrote:
> > hg is much better.  OTOH it does have one severe problem: it expects
> > you to check in before merging, which is the opposite of what cvs
> > users expect.  A cvs refugee, or anyone working on a project whose
> > leaders don't like merge changesets (yes, they exist) will notice new
> > changes upstream and decide to merge them into their current tree with
> > `hg pull -u', which is the equivalent of `cvs update'.
>
> Notice how -u is an option, and the default is _not_ update your current
> working state?  If supplying an option has a behavior you don't like, which
> it won't do if you leave the option off, where's the problem?
>
> (And one thing hg won't _ever_ do is throw <<<<<<< style crap into your source
> code when you pull, which you're implying is somehow desirable.)
>
> > However, that
> > rune's handling of merge conflicts is catastrophically bad and likely
> > to lead to the working tree being effectively destroyed, possibly
> > losing a great deal of work.
>
> This is a design issue.  Collisions happend during a merge, not during a
> checkin.  In a distributed source control system, a checkin always happens
> against a known state.  Therefore, if you do a pull from outside you're
> either doing an implicit merge (-u) or you're creating a new branch (if you
> do a checkin against an old version of the repository after pulling).
>
> It's not really a user interface issue, it's a difference between how
> distributed and centralized source control systems work.
>
> > As I've said, I think there is no point switching from cvs to svn.
> > It's true that cvs's lack of the concept of a changeset is a serious
> > problem and makes mirroring a cvs repository something of a challenge.
> > However, there is already software to reconstruct changesets from cvs
> > logs, and provided the cvs users use cvs in a sane and predictable way
> > (which current qemu upstream do) those conversion tools do work.
>
> Modulo being buggy and complicated.  But in theory they work, yes.  The
> current git mirrors are maintained from them, and I can limp along with that
> indefinitely.
>
> > What should those of us who want to collaborate using a drcs (so that
> > we can share our work-in-progress patches and generally avoid blocking
> > on upstream) do in the meantime ?
>
> Simple:
>
> A) Pick a repository as your upstream.  Doesn't matter which, just as long as
> you agree.
>
> or,
>
> B) Send patches around ala cherry-pick, which is what you have to do to send
> them upstream anyway.
>
> For the first 10 years Linus Torvalds's only source control system was the
> periodic release of tarball snapshots of his personal source tree.  Even CVS
> is only slightly worse than that.
>
> > Having a private mirror of a drcs is all well and good but no-one can
> > pull from anyone else because each cvs/svn->drcs conversion yields an
> > incompatible history.
>
> *shrug*  I'll live.
>
> > At the very least we need one drcs branch containing only changes from
> > the upstream cvs.  It has to be incrementally updated, automatically
> > and frequently, and generally be well maintained.
>
> Already exists.
>
> > Most of the potential users seem to be fans of git which is fine by
> > me.
>
> No, most of the existing mirrors are git based, and the potential users are
> lazy enough to use what's in front of us.  I note that the most popular
> cvs->hg conversion tool (tailor) had a bug in it for most of last year, due
> to depending on a package (cvsps) that was broken in Ubuntu 7.04.
>
> Mercurial itself had a new "convert extension" merged into mainline a few
> months ago, so it should now have cvs->hg functionality built in.  But it's
> brand new and I haven't fiddled with it yet.
>
> Personally, I'd much rather have a mercurial repository, but I'm lazy enough
> to live with git if it's there.  It is considerably more complicated than
> mercurial, and has a horrible user interface, but it still means I don't have
> to deal with CVS directly.

I don't think these kind of discussions are productive. If someone is
interested in pushing their favorite dcms they should do some kind of
study and publish it so other projects can benefit and not have these
discussions over and over.

Personally, anything other than git or SVN would make things difficult for me.

I think SVN is a good option. Easy to move from CVS, easy to use from
any dcms. I don't think anyone would prefer the status-quo against
SVN.

Picking a dcms on the other hand would probably cause discomfort on
other dcms's fans and people that don't care about the cms.

Best regards.

-- 
Felipe Contreras

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Rob Landley]

On Saturday 09 February 2008 10:49:49 Johannes Schindelin wrote:
> Hi,
>
> On Sat, 9 Feb 2008, Felipe Contreras wrote:
> > Right now I can't use qemu because a bug introduced in the last months
> > and with git-bisect I probably would be able to fix it myself.
>
> Just clone git://repo.or.cz/qemu.git, then.

I've been using git://git.kernel.dk/data/git/qemu.git although I personally 
prefer mercurial.  (It's easier to learn and to use, you get the web viewer 
for free, etc.)

The thing is, git and mercurial are roughly equivalent, they're both 
distributed source control systems and you can losslessly convert from one to 
the other and back again, because they have all the same metadata.  (See 
http://kernel.org/hg/linux-2.6 as an example of a mercurial mirror of a git 
repository.)

But the difference between centralized source control and distributed source 
control is huge.  The distributed ones store more information.  This means 
you can convert losslessly convert from svn->hg, but if you convert from 
hg->svn you lose information.  (So if you convert from hg->svn and then back 
from svn->hg, you have a different mercurial repository, and pulling from the 
original would be a bad idea because it would think it had lots of duplicate 
changes.)

And of course CVS isn't even a full fledged centralized repository, it's an 
ancient holdover from the 1980's that doesn't even have the concept 
of "changesets".  (In cvs, changes are tracked in individual files.  Changes 
that touch multiple files at the same time have to be collated after the fact 
by comparing timestamps and hoping the descriptions match up.  This is a 
brittle heuristic at best; CVS hasn't got this _concept_.  Doing a binary 
search for the change that introduced a bug is amazingly painful with CVS, 
and even proposing tracking renames violates the design assumptions.  Even 
patch knows how to touch more than one file at a time; CVS does not.)

It is possible to use a distributed source control system as if it were a 
centralized source control system.  Just accept all changes as patches, never 
pulling directly from any other trees.  And thus you can hold off on learning 
new distributed source control concepts indefinitely.

> Hth,
> Dscho

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Johannes Schindelin]

Hi,

On Mon, 11 Feb 2008, Rob Landley wrote:

> I've been using git://git.kernel.dk/data/git/qemu.git although I 
> personally prefer mercurial.  (It's easier to learn and to use, you get 
> the web viewer for free, etc.)

<rant>I really grow tired of people perpetuating how "easy" Mercurial is, 
without substantiating it.  Granted, git _used_ to be more difficult, but 
now?  No, really.</rant>

The biggest obstacle to using a distributed VCS is that many people do not 
grasp, and indeed do not even care about, the concept of a distributed 
VCS.

That's perfectly fine with me, if you don't want to use a distributed 
tool, I do not want to force it down your throat.  FWIW I am happily using 
git on top of CVS, thankyouverymuch.

Ciao,
Dscho

Re: Git/SVN/CVS? was Re: [Qemu-devel] What does code_copy_enabled do?

[Rob Landley]

On Monday 11 February 2008 15:28:17 Johannes Schindelin wrote:
> Hi,
>
> On Mon, 11 Feb 2008, Rob Landley wrote:
> > I've been using git://git.kernel.dk/data/git/qemu.git although I
> > personally prefer mercurial.  (It's easier to learn and to use, you get
> > the web viewer for free, etc.)
>
> <rant>I really grow tired of people perpetuating how "easy" Mercurial is,
> without substantiating it.

And the macintosh has a nicer desktop than Gnome, too. :P

> Granted, git _used_ to be more difficult, but 
> now?  No, really.</rant>

I wrote "http://kernel.org/doc/local/git-quick.html", so I'm not speakign 
entirely from ignorance when I say that Mercurial is way the heck easier to 
set up and to use.

In mercurial, the human readable web repository viewer and the server you pull 
from are the same thing (and part of the same package).  They're different 
packages in git, set up differently, and live at arbitrarily different URLs 
such that knowing where to pull from doesn't let you know where a web 
repository viewer is (or even if there _is_ one, since it's a lot of extra 
work to set up in git but comes free in mercurial).  There's also no 
mercurial equivalent to the "git update-server-info" comand because it 
doesn't need one, and if you're behind a firewall that only allows http 
access you can pull from mercurial but not from git.  Also, since the 
mercurial repository uses apache as its server just use https:// and you get 
encryption for free, while git has to reimplement all that.  You never have 
to "pack" or "git gc" a mercurial repository.  You don't have to install a 
seperate documentation package in order for "hg help command" to work.  The 
mercurial command syntax doesn't vary wildly depending on which version you 
have installed, in git it's totally different before 1.5.0 and after...

Shall I go on?  I dunno an archive for the users at kernel.org mailing list 
but the vast majority of the traffic is "strange, subtle, and painful things 
that can go wrong with git".  (It's not a high traffic list, but still.)

That said, it's the source control system the kernel guys use, and it _is_ the 
same basic concepts as any other distributed SCM (with a horrible user 
interface).  I don't _object_ to using it, I just don't prefer it.

> The biggest obstacle to using a distributed VCS is that many people do not
> grasp, and indeed do not even care about, the concept of a distributed
> VCS.

For me, going from svn to hg was less pain than going from cvs to svn had 
been.

I like mercurial because going "hg log -v", or "hg update -r 12345" is an 
entirely local operation that doesn't have to go out on the network.  I can 
tell mercurial to spit out a tarball of any arbitrary historical version (or 
just put it in a directory directly), again without waiting for access to a 
server and hoping it's up.

You get darn spoiled by that, really quick.  (And this doesn't even count the 
maintainer-only stuff like being able to do checkins on plane flights or long 
car trips.  And said checkin taking a fraction of a second to commit, and 
_never_ having a conflict during the commit stage.)  You don't have to worry 
about new concepts until you want to use branching and merging, which I 
really don't much.

> That's perfectly fine with me, if you don't want to use a distributed
> tool, I do not want to force it down your throat.  FWIW I am happily using
> git on top of CVS, thankyouverymuch.

*shrug*  Now that the git mirror I use is updating again, I admit my 
motivation on this topic's dried up a bit. :)

> Ciao,
> Dscho

Rob
-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.