[gentoo-dev] Re: SCM choices

[Marijn Schouten (hkBst)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Kevin F. Quinn wrote:
> On Wed, 28 Mar 2007 07:58:59 -0400
> Chris Gianelloni <wolf31o2@g.o> wrote:
>
>> Please, everyone, go back and read the actual *facts* that were
>> discovered using copies of *our* repositories before going around
>> using data from outside sources.
>
> Alec Warner's test results are here, of course:
>
> http://www.gentoo.org/proj/en/infrastructure/cvs-migration.xml

I've looked at this just now and in the past and at the last thread in which this was discussed
(http://marc.info/?t=116855132300001&r=1&w=2) and
http://dev.gentoo.org/~antarus/projects/soc/glep-0052.txt and there doesn't seem to be any hard data
which can be used to base an informed decision on. Things like git not supporting partial syncs were
brought up as being too painful for non-broadband users and disagreed with
(http://marc.info/?l=gentoo-dev&m=116918412629635&w=2). You can find some more issues like this in
the entire thread. Furthermore only git and svn (svk) seem to have been investigated and it is
unclear which versions were used. If you believe, like me, that non-distributed SCMs are broken,
then this leaves only git (and svk but "It is certainly not the optimal distributed VCS solution.").

These were the reasons I decided to look and see what other infos could be had on the internet. Of
course it is hard to come up with good measures of performance and I've certainly found very little
hard data.

So in light of all that I don't think it is wasteful to restart this discussion.

Of course not everyone is yet convinced that non-distributed SCMs are broken, so perhaps it would be
good if I ask the following question _here_ instead of privately.


Chris,
if I am to continue my plan of producing frequent releases of minimal amd64 install cd, then it
would probably help if I can use some versioning control and you might be interested in having easy
access to any changes I make. How can we achieve both? I believe the stuff I'm interested in is in
some CVS repository. As I see it I have the following options:

1) get commit access to the repository and start a branch in there. Merging may not be too hard, I
don't really know. However CVS commit access is not something that is given lightly. It would vice
versa also mean that you would have commit access to my stuff, which I might not like.

2) file bugs with patches attached. But maybe you just want to forget about releases until 2007.1
comes along once 2007.0 is finished.

3) fork the code or convert the repository into a repo of my own. Even if I choose to use the same
kind of repo (CVS in this case), then how hard will merging be? Again, this goes both ways.

I hope I missed something here, but of the three the third looks the most appealing and likely with
me forking into darcs probably. I don't think this issue would be here if the code were in a
distributed SCM, but maybe by the time 2007.1 is due I will have amassed enough interesting changes
that it is easier for you to then just clone my distributed repo ;P.


So can we please discuss what distributed SCM is best for the tree or likely to be in the future and
what hard data obtained with what tests should be gathered to rank SCMs and what feature differences
there are and how much we should care about them?

Marijn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGDi9op/VmCx0OL2wRArS/AKDGGC74l6xMFStjt3wS6PcOlTj/9wCdGwuR
8evRaXm3V8G7WWfUaC9luNM=
=XPYE
-----END PGP SIGNATURE-----
-- 
gentoo-dev@g.o mailing list