Re: [gentoo-dev] Re: SCM choices

[Chris Gianelloni <wolf31o2@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 5294 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]