Re: I have end-of-lifed cvsps

From: Eric S. Raymond <esr@thyrsus.com>
Date: Dec 12, 2013, 19:39 UTC
Message-ID: <20131212193918.GA17529@thyrsus.com>
In-Reply-To: <CACPiFCJ22xiedXAoQktMLd=gASgD0NS24Pya9TvCo9aQP5JaBQ@mail.gmail.com>

Martin Langhoff <martin.langhoff@gmail.com>:

Show 19 quoted lines

> IIRC, making the output stable is nontrivial, specially on branches.
> Two cases are still in my mind, from when I was wrestling with cvsps.
> 
> 1 - For a history with CVS HEAD and a long-running "stable release"
> branch ("STABLE"), which branched at P1...
> 
>    a - adding a file only at the tip of STABLE "retroactively changes
> history"  for P1 and perhaps CVS HEAD
> 
>    b - forgetting to properly tag a subset of files with the branch
> tag, and doing it later retroactively changes history
> 
> 2 - you can create a new branch or tag with files that do not belong
> together in any "commit". Doing so changes history retroactively
> 
> ... when I say "changes history", I mean that the importers I know
> revise their guesses of what files were seen together in a 'commit'.
> This is specially true for history recorded with early cvs versions
> that did not record a 'commit id'.

Yikes! That is a much stricter stability criterion than I thought you were specifying. No, cvs-fast-export probably doesn't satify all of these. I think it would handle 1a in a stable way, but 1b and 2 would throw it.

I'm sure it can't be fooled in the presence of commitids, though, because when it has those it doesn't try to do any similarity matching. And (this is the important point) it won't match any change with a commit-id to any change without one.

What I think this means is that cvs-fast-export is stable if you are using a server/client combination that generates commitids (that is, GNU CVS of any version newer than 1.12 of 2004, or CVS-NT). It is *not* necessary for stability that the entire history have them.

Here's how the logic works out:

1. Commits grouped by commitid are stable - nothing in CVS ever rewrites
those or assigns a duplicate.

2. No file change made with a commitid can destabilize a commit guess
made without them, because the similarity checker never tries to put both 
kinds in a single changeset.

Can you detect any flaw in this?

-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>