Re: The essential problems of moving from CVS

[David Holland <dholland-tech%netbsd.org@localhost>]

On Sat, Jan 16, 2010 at 11:32:47AM +0900, Curt Sampson wrote:
 > > But I don't understand this claim; rejecting some particular instance
 > > of distributed SCM because that instance has currently insurmountable
 > > technical problems is not "a decision not to seek the advantages".
 > 
 > This is where we disagree; you believe that the problems with git are
 > insurmountable. I believe that a not unreasonable amount of coding work
 > (to fix the conversion issues and set up scripts to deal with some
 > NetBSD-specific usage issues such as $NetBSD$ tag expansion) and some
 > changes to the way we work (such as a different way of dealing with the
 > issues for which we currently use partial checkouts) would surmount the
 > problems.

That is not a disagreement, that's just terminology. The problems are
insurmountable in the sense that we cannot just start using git.
Hacking on git is required; furthermore, it appears that some of the
things we need/want may not be palatable to git's upstream, in which
case we're also stuck with keeping and maintaining local mods or
extensions.

However, serious hacking on almost any of the systems is likely to
bring it to a state where we can use it. And in this sense it's also
not insurmountable to switch to something that doesn't yet exist;
there's nothing particularly unreasonable or especially difficult in
the requirements list we have, so implementing a new system is a SMOP.

How much work is really required for any of these choices is not
clear. For the most part nobody here seems especially motivated to do
that work, so in general we're waiting for people upstream to get
around to it. But of course if someone wants to put the work in,
they're welcome to do so.

Meanwhile, until someone does or things improve upstream, talk of
adopting one or another system is just talk.

 > > The current status is that no available system is suitable....
 > 
 > It is my opinion that this is, in part, because we've "decided" (in the
 > usual NetBSD default way) on a set of requirements that makes this so.

I see no sign that this is true, and I don't see any reason to believe
that the technical gaps can be filled by compromising the project's
development practices, even if that were a desirable thing to do.

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