On Wed, Dec 18, 2013 at 1:21 AM, Eric S. Raymond <esr@xxxxxxxxxxx> wrote:
> Jakub Narębski <jnareb@xxxxxxxxx>:
>>> No, cvs-fast-export does not have --export-marks. It doesn't generate the
>>> SHA1s that would require. Even if it did, it's not clear how that would help.
>>
>> I was thinking about how the following part of git-fast-export
>> `--import-marks=<file>`
>>
>> Any commits that have already been marked will not be exported again.
>> If the backend uses a similar --import-marks file, this allows for incremental
>> bidirectional exporting of the repository by keeping the marks the same
>> across runs.
>
> I understand that. But it's not relevant - cvs-fast-import doesn't know about
> git SHA1s, and cannot.
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?
>> How cvs-fast-export know where to start exporting from in incremental mode?
>
> You give it a cutoff date. This is the same way cvsps-2.x and 3.x worked,
> and it's what the cvsimport wrapper expects to pass down.
Nice to know.
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).
>> BTW. does cvs-fast-export support incremental *output*, or does it
>> perform also incremental *work*?
>
> 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?
Anyway I hope that incremental CVS import would be needed less
and less as CVS is replaced by any more modern version control system.
>> Anyway, that might mean that generic fast-import stream based incremental
>> (i.e. supporting proper thin fetch) remote helper is out of question, perhaps
>> writing one for cvs / cvs-fe would bring incremental import from CVS to
>> git?
>
> Sorry, I don't understand that.
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.
--
Jakub Narębski
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html