Re: The essential problems of moving from CVS

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

On Thu, Jan 14, 2010 at 12:58:49PM +0900, Curt Sampson 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?

Well, sure. I guess the question is: what's the cost model you
envision for having wrong or missing history in the master repository?
It seems to me that there's a pretty large fixed cost (keeping cvs and
anoncvs up indefinitely) which itself possibly outweighs the cost of
fixing conversion issues. Beyond that, missing history (that is,
clearly identifiable holes) would be a pretty big hassle for me; I
search back a lot. *Wrong* history I think should not be tolerated.
For a lot of things in the system, particularly drivers, the only
useful reference we have for chasing bugs is "it worked back in 2003".
If that gets silently mixed up it could waste days or weeks of
someone's time, or worse, and I don't think any advantages of
switching to anything outweigh that.

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

It is nonetheless something we should consider doing; we should also
prefer systems that would allow us to splice in the CSRG history later
without doing a complete repository rebuild.

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

That's true, but it is also pointless to discuss e.g. git-specific
workflow concerns if there's no way that git is ever going to work for
us. Some such concerns are more or less independent of the specific
SCM, but not that many; after all, despite the vast similarity between
git and mercurial they still have substantially different branch
semantics.

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

You've forgotten at least two possibilities:

   1 1/2. We hash through all the problems with the available systems
   and conclude that we have to stick with CVS because nothing else is
   viable for us.

   2.d) write something new and move to that.

Option 1 1/2 there has been the consistent result in the past, and I
don't think anything has changed that much since the last go.

(Also, when you say "a DVCS" do you mean git, mercurial, monotone,
bazaar, or what? They're not all the same except in very broad
outlines.)

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

Well, several points that have been raised in the past, which are all
significant considerations in the putative decision, require some
practical experience:

   - How big is the packed history? Can I still keep /usr/src on a
     system with e.g. only a 4G disk?

   - Does the branching and tagging scheme adequately support the
     branches and tags we already have? What would releng's experience
     be like?

   - Does the system perform acceptably on a tree and repository of
     the size (both in space and history depth) that ours has? (This
     was not such a big concern for git, which is known to be
     performant, but it's a big deal for some other systems. But also
     note the recent complaints about the converted repo.)

Deciding to adopt git without answering these questions (and there may
have been others; I have notes but they aren't perfect) would be
irresponsible. Plus of course one can make decisions all day without
getting anywhere useful if the conversion steadfastly doesn't work.

Keep in mind that until this last round of tries in the last few
months nobody had been able to successfully convert the repo to
anything, ever. So having it finally work is a significant chunk of
progress, even if some of what comes out is wrong.

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

Well, here are two workflow-related issues that have come up in the
past:

   - How do you correct a botched change comment?

   - How do you retroactively expunge a version or changeset that is
     (later) found to be e.g. not legal to distribute?

Both of these are inherently problematic with distributed SCMs, but I
think we want a solution for the former if at all possible, and as a
matter of legal exposure we AIUI must have the second.

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

There's a third category of issue, namely technical problems in the
target system itself that are not (strictly speaking) workflow, but
don't have anything to do with conversion either.

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