tech-repository archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: The essential problems of moving from CVS



On Fri, Jan 15, 2010 at 03:16:20PM +0900, Curt Sampson wrote:
 >>> I reckon the possibilities are:
 >>> 
 >>>     1. We end up with the usual NetBSD argumentative mess, nothing can
 >>>     move forward, and we stick with CVS because we can't make a decision.
 >>> 
 >>>     2. We manage to do a reasonable analysis of the situation, and come
 >>>     to a decision to:
 >>>    a) stick with CVS,
 >>>    b) move to Subversion, or
 >>>    c) move to a DVCS.
 >> 
 >> You've forgotten at least two possibilities:
 >> 
 >>    1 1/2. We hash through all the problems with the available systems
 >>    and conclude that we have to stick with CVS because nothing else is
 >>    viable for us.
 >> 
 >>    2.d) write something new and move to that.
 > 
 > I wasn't clear about this, but those are both possible consequences of
 > decisions b) and c). I guess I should have phrased those "move to"s as
 > "decide to attempt to move to"s instead.

Well, I think we've already decided to move to anything we can find
that we can make serve our purposes adequately.

 > > Option 1 1/2 there has been the consistent result in the past, and I
 > > don't think anything has changed that much since the last go.
 > 
 > Well, I believe that part of that is because we'd actually, in our heart
 > of hearts, made decision a), because we would not accept anything that
 > didn't work exactly like CVS for all existing features.

And (as one of the leading people who keeps coming up with this
result) I don't think this is true. I've been using Mercurial for
about three years for (now nearly all of) my own projects, and I
wouldn't voluntarily go back to CVS. Meanwhile, the sense I have is
that we're fed up enough with the problems CVS gives us that we'll be
happy to move to anything else as long as it doesn't buy us worse
problems.

What constitutes "worse" is of course somewhat up for grabs...

 > > (Also, when you say "a DVCS" do you mean git, mercurial, monotone,
 > > bazaar, or what? They're not all the same except in very broad
 > > outlines.)
 > 
 > I mean them all, because all I was looking for were the broad outlines
 > of whether even the idea of a DVCS would be acceptable. I strongly
 > believe that a possible reaction from (at least some of) the developers
 > would be: "no DVCS at all; it's to different."

I don't think that's the case, or at least not from a subset large
enough to avoid being shouted down. Disconnected operation is a big
lure; so is cheap branching. (We could have both of these things with
a centralized system, and avoid paying most of the overt costs of
distribution, but we'd have to write it ourselves.)

Hash codes for version numbers does get some resistance. This is one
of those things that's probably worth just sucking up, though, unless
we really want to write our own system.

A bigger concern is whether the SCM can stash the old CVS version
numbers in searchable metadata somewhere for crossreferencing against
old mailing list postings and bug reports. I'm told Monotone can do
this (like it can do anything you want, except for scale to our size
repo...) but AFAIK it isn't readily done with either Git or Mercurial.

 > > Deciding to adopt git without answering these questions (and there may
 > > have been others; I have notes but they aren't perfect) would be
 > > irresponsible.
 > 
 > Right. Again, I'm not saying we make a decision to adopt Git: I'm saying
 > we make a decision that it would be possible to adopt git if it doesn't
 > fail on the most important criteria. Sorry about not being clear about
 > this before.

Ah. In that case... well, if git were flatly ruled out nobody would be
bothering to experiment with it. At this point I think we'd seriously
consider adopting a version control system that required sacrificing
chickens under the full moon, if it worked.

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index