Re: I have end-of-lifed cvsps

From: Eric S. Raymond <esr@thyrsus.com>
Date: Dec 18, 2013, 16:27 UTC
Message-ID: <20131218162710.GA3573@thyrsus.com>
In-Reply-To: <CANQwDwdgZUWcgyZCWoDni+e9jgQ+8j0Yn_HMxiMn5OHzsRzjwQ@mail.gmail.com>

Jakub Narębski <jnareb@gmail.com>:

Show 5 quoted lines

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

Show 8 quoted lines

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

Show 7 quoted lines

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