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 2010-01-13 20:48 +0000 (Wed), David Holland wrote:

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

I expect that we'll only find the answers to that sort of thing as we
get deep down into the details of the conversion itself.

> If the conversion does not get some things wrong as
> such but only leaves clearly identifiable holes, why not fill in the
> holes?

If they cost-benefit trade-off is seen as worth it, indeed, why not fill
in the holes? If the costs are seen to exceed the benefits, why not take
an alternate, cheaper route?

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

That's a big *if*. I personally don't feel that we should not consider a
repository move unless we get CSRG history with it. That position leaves
us with CVS and still not CSRG history. But of course this would be
something determined by the entire project.

>  > I'm sorry; I'd thought that the basic question I posed was something we
>  > could just poll developers with.
> 
> Because asking questions like that leads to (has already led to) long
> unproductive bikeshed threads that produce no useful conclusions.

Indeed, but it seems to me that we're in that position whether or not we
have a perfect git conversion ready or not. That's an issue that has to
be solved if we're going to move at all.

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.

Only in one of these four cases is there a possibility of moving to git.
In all the other cases, the effort put into a git conversion is wasted,
except to the extent that people profit from it personally.

> Go ahead and start another one if you want...

I was trying to, but I think I'm getting tired now. Even on this list
I feel as if others don't want to bring up the subject, and I wouldn't
really want to go into -developers without a lot of support from the
people here.

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

Indeed, I see your point, and understand perfectly. (I've been a NetBSD
developer for almost a decade and a half, and the culture hasn't changed
much.)

Anyway, though I'm not going to push this further myself, I will be
happy to help support anybody else who wants to take up the torch of
contemplating the effects on developer workflow (as opposed to technical
conversion difficulties) of a move to Subversion or a DVCS.

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


Home | Main Index | Thread Index | Old Index