Re: The essential problems of moving from CVS

[Curt Sampson <cjs%netbsd.org@localhost>]

On 2010-01-12 16:23 +0000 (Tue), David Holland 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. That's the only part of the anoncvs infrastructure we
need to maintain.

2. If that really is too much work, it's safe to shut it down anyway,
if we don't mind the bandwidth use of people pulling the full repo via
rsync to look up something there.

> ...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.

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?

> 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.

> 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?

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.

> 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.

> 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?

cjs
-- 
Curt Sampson         <cjs%cynic.net@localhost>         +81 90 7737 2974
             http://www.starling-software.com
The power of accurate observation is commonly called cynicism
by those who have not got it.    --George Bernard Shaw