From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HYoBz-0001uk-Ee for garchives@archives.gentoo.org; Tue, 03 Apr 2007 18:57:20 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l33IuKPs028021; Tue, 3 Apr 2007 18:56:20 GMT Received: from smtp03.atlngahp.sys.nuvox.net (smtp-out3.atlngahp.sys.nuvox.net [70.43.63.20]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l33IsTSO025749 for ; Tue, 3 Apr 2007 18:54:30 GMT Received: from [10.3.23.140] (216.215.202.4.nw.nuvox.net [216.215.202.4]) (authenticated bits=0) by smtp03.atlngahp.sys.nuvox.net (8.13.1/8.13.1) with ESMTP id l33IsRqV029047 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Tue, 3 Apr 2007 14:54:27 -0400 Subject: Re: [gentoo-dev] Re: SCM choices From: Chris Gianelloni To: gentoo-dev@lists.gentoo.org In-Reply-To: <46128F35.60804@gentoo.org> References: <1174788467.4883.29.camel@bruichladdich> <200703280938.19798.csawtell@paradise.net.nz> <20070327225321.2cad4182@snowflake> <200703281030.57196.csawtell@paradise.net.nz> <20070327234305.7760e0a7@snowflake> <460A43AF.3090105@gentoo.org> <1175083139.10622.9.camel@inertia.twi-31o2.org> <20070328152313.786dd81c@c1358217.kevquinn.com> <460E2F68.6000807@gentoo.org> <1175609463.8202.29.camel@inertia.twi-31o2.org> <46128F35.60804@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-0YV0SCqlqATVnyh2TD6y" Date: Tue, 03 Apr 2007 14:54:26 -0400 Message-Id: <1175626466.8202.56.camel@inertia.twi-31o2.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.8.3 X-Archives-Salt: 56ece04c-3609-4c09-9bd9-5175af2465ce X-Archives-Hash: 5a12c0740a7a731f1ee05475b3930907 --=-0YV0SCqlqATVnyh2TD6y Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-04-03 at 19:30 +0200, Marijn Schouten (hkBst) wrote: > I just don't think it is obvious what tests should be performed. Furtherm= ore the difference between > the different systems is not just performance, but also features. So we n= eed to discuss what > standards any candidate SCM should measure up to. No, we really don't. First off, let's look at things we know we need. This is pretty much the CVS feature set. Next, look at things we want. Does any SCM provide things we want? Now, I'm not going to reiterate all the junk people have said they want, since it's all archived for prosperity. Next, start comparing the things we *require* and the things we *want* in each SCM. Some good metrics people have already been using are server-side disk space, client-side disk space, bandwidth, time for checkout, time for commit, time for update... Also, remember that the needs of the few definitely doesn't outweigh the needs of the many. If 99.9% of the developer pool are doing only checkout/update/commit cycles, then having a 50% drop in performance or a 700% increase in disk usage only to gain features that don't affect the 99.9% make a migration no longer worth it. This is what I mean by using numbers to back up your ideas. > I thought the shortcomings in features of CVS in comparison with SVN were= understood. Given in turn > SVN's shortcomings in comparison to distributed SCMs and the abundance an= d maturity of them it seems > to me that the only decision to be made is what to switch to. What shortcomings, exactly? This is something that you have to quantify. CVS does $x CVS does not do $y I simply have not seen much of anything that would be useful to a large enough section of our developer pool to be worth the problems of a migration. About the only thing I see is "svn cp" to preserve history. I see lots of reasons for it in non-tree repositories, but little in the tree, which already has branches and tags disabled, among other things. > > I don't get why you discuss a distributed SCM, then proceed to talk > > about minimal CD + releases stuff which has nothing to do with the main > > tree. >=20 > Just an example to demonstrate how non-distributed SCM impose artificial = restrictions. You wanted to > be convinced, right? I realize the specifics of the example, specifically= the expected small extent > of divergence, make this a bad example in practice. But think about the t= heory. OK. You weren't able to successfully demonstrate anything to me, then. I saw nothing in your mail that showed me why what you described would be a problem, especially considering the examples you used. > But let me try again. Suppose you are developing an ebuild or are coopera= ting in developing an > ebuild or set of ebuilds with eclasses such as happens now in overlays. S= uch overlays could just be > branches in the same repository with easy merging between branches which = preserves history. All with > one tool. I guess I've just never had the need to do anything of the sort. I'm perfectly capable of using revision bumps and other methodologies already in use in the main tree in my overlays. Why do we need two sets of practices? Why do we need to modify the main tree to fit the model of the much smaller and less utilized overlays? > It would also empower people who don't have push access to the tree or to= a specific overlay or to > any overlay, by making it possible for them to do everything people with = push access do except > pushing, instead of also making it very hard to use the same SCM. Like what? Qualify your statements. I don't use other SCM software, like many of our developers/users. If you're going to try to tell me that I can't do something I don't want to do, or don't even know is possible, you won't convince me without compelling examples. My point is that instead of discussing all of this yet again, you get together some features you think are required and why, as well as some performance metrics, as I stated above, and try approaching this from a more technical front and less of an emotional one. Like I said, I don't care which SCM you like. You shouldn't care which one I like. There's no way we could ever please everyone, so why even bother to switch? > - From some discussion on irc I learned that lack of tree and history sli= cing are two concerns of > git's readyness. I hope to do some tests on the tree slicing soon. Excellent. This was something that wasn't available before, so if you're wanting to test it with a newer git that does this well, then that is something we can look at as something that has changed. > I also learned that darcs does not support enough architectures, most imp= ortantly mips. Therefore > I'd like to know what architectures need to be supported by a candidate S= CM. Ideally, all of them. I would consider dropping support for an architecture we support currently a strong reason to never consider that SCM. If I cannot commit from the machine I'm doing a KEYWORD request on, the SCM fails IMO. --=20 Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation --=-0YV0SCqlqATVnyh2TD6y Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.3 (GNU/Linux) iD8DBQBGEqLikT4lNIS36YERAg1QAJ92VZFTmI6cXCUttu3ISzjmkrziGACdFbGD wsVqVji571RCs1S+3mfJRx0= =NZdG -----END PGP SIGNATURE----- --=-0YV0SCqlqATVnyh2TD6y-- -- gentoo-dev@gentoo.org mailing list