Re: I have end-of-lifed cvsps

Jakub Narębski [off-list ref]:

It is a bit strange that markfile has explicitly SHA-1 (":markid <SHA-1>"),
instead of generic reference to commit, in the case of CVS it would be
commitid (what to do for older repositories, though?), in case of Bazaar
its revision id (GUID), etc.  Can we assume that SCM v1 fast-export and
SCM v2 fast-import markfile uses compatibile commit names in markfile?

For use in reposurgeon I have defined a generic cross-VCS reference to
commit I call an "action stamp"; it consists of an RFC3339 date followed by 
a committer email address. Here's an example:

	 2013-02-06T09:35:10Z!esr@thyrsus.com

In any VCS with changesets (git, Subversion, bzr, Mercurial) this
almost always suffices to uniquely identify a commit. The "almost" is
because in these systems it is possible for a user to do multiple commits
in the same second.

And now you know why I wish git had subsecond timestamp resolution!  If it
did, uniqueness of these in a git stream could be guaranteed.

The implied model completely breaks for CVS, of course.  There you have to 
use commitids and plain give up when those don't exist.
 

I think it would be possible for remote-helper for cvs-fast-export to find
this cutoff date automatically (perhaps with some safety margin), for
fetching (incremental import).

Yes.
 

quoted

As I tried to explain previously in my response to John Herland, it's
incremental output only.  There is *no* CVS exporter known to me, or
him, that supports incremental work.  That would be at best be impractically
difficult; given CVS's limitations it may be actually impossible. I wouldn't
bet against impossible.

Even with saving (or re-calculating from git import) guesses about CVS
history made so far?

Even with that.  cvsps-2.x tried to do something like this.  It was a lose.
 

Anyway I hope that incremental CVS import would be needed less
and less as CVS is replaced by any more modern version control system.

I agree.  I have never understood why people on this list are attached to it.

I was thinking about creating remote-helper for cvs-fast-export, so that
git can use local CVS repository as "remote", using e.g. "cvsroot::<path>"
as repo URL, and using this mechanism for incremental import (aka fetch).
(Or even "cvssync::<URL>" for automatic cvssync + cvs-fast-export).

But from what I understand this is not as easy as it seems, even with
remote-helper API having support for fast-import stream.

It's a swamp I wouldn't want to walk into.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>