Re: The essential problems of moving from CVS

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

On Wed, Jan 13, 2010 at 08:23:39AM +0900, Curt Sampson wrote:
 > > Yes, except that (1) since maintaining anoncvs is work, it's desirable
 > > to be able to shut it down....
 > 
 > 1. Keeping a cvs pserver entry for port 2401 in /etc/inetd.conf is not
 > much work at all.

As spz pointed out, there's much more to it than that.

 > > ...and (2) having history readily available, as opposed to
 > > theoretically available off in a corner somewhere, is important.
 > 
 > I'm not clear what you mean here, since I also think that "having
 > history readily available...is important" and have stated that we'll
 > have to be able to do a conversion that preserves enough history to do
 > the common tasks one needs it for.

Yes, and what constitutes "enough"? If the conversion gets some things
wrong, where/how are we supposed to determine that the converted
history is wrong and therefore one has to go look at the old repo off
in the corner? If the conversion does not get some things wrong as
such but only leaves clearly identifiable holes, why not fill in the
holes?

 > So does this mean you agree with me here, and have no objections? Or
 > does it mean you disagree with me, and think that having anything less
 > that absolutely perfect history (as opposed to "not the same but good
 > enough for the common tasks") is acceptable?

I don't know, because it's not clear to me what you mean.

 > > In fact, it's important enough that far from dropping history I think
 > > we ought to be taking the opportunity to merge the CSRG history to
 > > have it all in one pot.
 > 
 > I don't see how we can easily do that, since the CSRG history includes
 > code we are not legally allowed to distribute.

AIUI, this is believed to be no longer a problem if someone takes the
time to get all the ducks lined up.

 > > There's no point going to a lot of trouble figuring out what the
 > > practical impact of switching will be (on more than just "workflow")
 > > if it's not going to work in the first place.
 > 
 > I'm sorry; I'd thought that the basic question I posed was something we
 > could just poll developers with. So can you give me a bit more detail
 > about why just asking "would a DVCS ever be acceptable" is going to take
 > so much more time than doing all the research and conversion effort to
 > figure out how much more history (than we already can convert) we would
 > be able to convert, and how much it costs for each additional increment
 > of history?

Because asking questions like that leads to (has already led to) long
unproductive bikeshed threads that produce no useful conclusions. Go
ahead and start another one if you want...

 > It seems to me, in my naivety, that we already have a fair amount of
 > information about how much work it is to convert to git, and some idea
 > of how much more we'd have to do to fix the various bits of lossage,
 > should we chose to do so, and yet we have no idea at all if git would be
 > acceptable to use.

See the tech-repository archives from, as I recall, summer of 2008. I
tried to collect this information and (as I think I mentioned already
a couple days ago) got roundly flamed for it, to the point where I
gave up and nobody else has tried since.

 > > Also, trying to decide what we want to switch to *before* doing
 > > *either* analysis (as your prior mail suggested) is really backwards.
 > > That leads to choosing a system first and predetermining the result of
 > > the feasibility studies so that the chosen system wins.
 > 
 > Sorry, I wasn't clear. I didn't intend my list of choices to be a final
 > decision. I intended it to be the "here's what we'll start doing more
 > research on next" decision.

Ah. Well, what I described has happened before... :-/

 > > I don't see any reason to believe switching will produce anything like
 > > that kind of overall net benefit.
 > 
 > That's not my point: my point is, are you willing to switch back and
 > forth between analysing the mechanics of some particular conversion
 > and asking whether the project would ever want to do such a thing, or
 > are you insistent that we must not even consider whether the project
 > would use a new workflow and whether we need perfect history until we've
 > determined that git, say, can preserve prefect history and actually
 > written all of the code to do the conversion?

I don't see a problem with any of that; I think the issue is that a
lot of this was hashed to death already within the recent recollection
of most of the people reading tech-repository, plus because until very
recently *nothing* worked it's a significant item in the requirements
list.

As for workflows, git and everything else support various possible
workflows. I think if you suggest adopting the Linux kernel workflow
that it won't go over very well...

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