Jakub Narębski <jna...@gmail.com>:
> 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!e...@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.
> > 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>
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
