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 04:52:54PM +0900, Curt Sampson wrote:
 > > Well, I think we've already decided to move to anything we can find
 > > that we can make serve our purposes adequately.
 > 
 > Ha! :-)
 > 
 > Ok, the "ha" is a joke, but I was under the impression that we've
 > "decided" to bog ourselves down doing nothing but arguing. But did I
 > miss a mandate from core or something like that saying that, could the
 > technical problems be overcome, Git is acceptable?

No; I'm reporting what I perceive to be the consensus based on having
observed/participated in many of the bikeshed sessions on the subject
over the past couple years. The various problems caused by CVS have
annoyed a lot of people. Any system that has rename, atomic commits,
sane branches, and fast tagging is going to appeal to a lot of people,
more still if it supports disconnected operation; my guess is that
we'll end up adopting the first one that comes along with no major
downsides.

This does not stop the people who are deeply dedicated to one
particular system from being blind to its faults. Nor does it generate
much consensus about what constitutes a major downside.

 > >> 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.
 > 
 > Oh, I'm the same for Subversion since about five years ago, and Git now.
 > If I never touch CVS again I couldn't be happier.
 > 
 > But in 15 years with the NetBSD project, I've learned that there are
 > always people out there who will violently protest the loss of a single
 > small, hardly-used feature, even if we get a hundred new and better
 > features in exchange. Or even a change that doesn't lose functionality,
 > such as:
 > [hash codes]

That does lose functionality; it loses you the ability to establish
the ordering of two (or more) versions in order without pasting them
into the SCM. Granted you don't exactly get this with CVS either if
multiple branches are involved, but that's not the common case.

The extent to which this matters is a different question.

 > > Hash codes for version numbers does get some resistance. This is one
 > > of those things that's probably worth just sucking up, though....
 > 
 > I entirely agree that it's "worth sucking up." The problem is, a lot of
 > people won't, I expect. (I could be wrong here.)

Well, if it's the only thing between them and getting their atomic
commits and disconnected operation, they'll grumble and put up with
it.

The really hard question, actually, is: is it worth writing our own?
It obviously isn't, because it'd be a big project taking up time and
energy that would be better spent on other things... except that this
way we can have a centralized system with rename, atomic commits, sane
branches, fast tagging, and disconnected operation... and numbered
versions and whatnot too. And don't forget that we have the current
generation of SCM tools essentially because some Linux folks decided
it was worth writing *their* own.

 > So the basic summary is: if we're really over the hump where git has
 > been mooted as acceptable by enough developers that the naysayers are
 > not going to be able to stop it, and people really are fine with things
 > like hashes for version numbers, what I'm proposing we do is done.
 > 
 > In which case, post a note to developers@ and say, "The project to
 > move NetBSD from CVS to get is moving along nicely, and these are
 > the issues remaining to deal with. We hope to get them solved over
 > the next year or so and then start the conversion."
 > 
 > I'm not sure if I'll enjoy reading the result of that or not. :-)

Hee. But it would be more accurate to say "from CVS to
git/mercurial/monotone/whatnot or maybe subversion or maybe write our
own". After all, everything said above applies equally to any of the
serious contenders. Then you'd just get flamed for claiming that there
was progress. :-)

I myself would rule out subversion but there's not widespread
agreement on that.

Meanwhile, one of the issues about git that I don't think we currently
have a really clear idea of is: to what extent does it really depend
on perl?

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


Home | Main Index | Thread Index | Old Index