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. Furthermore > the difference between > the different systems is not just performance, but also features. So we need > 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 and > 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. > > 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 > theory. 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 cooperating > in developing an > ebuild or set of ebuilds with eclasses such as happens now in overlays. Such > 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 slicing > 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 > importantly mips. Therefore > I'd like to know what architectures need to be supported by a candidate SCM. 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. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation
signature.asc
Description: This is a digitally signed message part
