On Tue, Dec 17, 2013 at 11:57 AM, Jakub Narębski <jna...@gmail.com> wrote:
> Martin Langhoff wrote:
>> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond<e...@thyrsus.com>  wrote:
>>> You'll have to remind me what you mean by "incremental" here. Possibly
>>> it's something cvs-fast-export could support.
>> User can
>>   - run a cvs to git import at time T, resulting in repo G
>>   - make commits to cvs repo
>>   - run cvs to git import at time T1, pointed to G, and the import tool
>> will only add the new commits found in cvs between T and T1.
> I wonder if we can add support for incremental import once, for all
> VCS supporting fast-export, in one place, namely at the remote-helper.
> I don't know details, so I don't know if it is possible; certainly
> unstable fast-export output would be a problem, unless some tricks
> are used (like remembering mappings between versions).

You could do this by mapping some CVS revision identifier (like a hash
over the file:revision pairs if nothing better is available), and that
would be useful when trying to match up the git commit from a later
import against the existing commits from an earlier import.

HOWEVER, this only solves the "cheap" half of the problem. The reason
people want incremental CVS import, is to avoid having to repeatedly
convert the ENTIRE CVS history. This means that the CVS exporter must
learn to start from a given point in the CVS history (identified by
the above mapping) and then quickly and efficiently convert only the
"new stuff" without having to consult/convert the rest of the CVS
history. THIS is the hard part of incremental import. And it is much
harder for systems like CVS - where the starting point has a broken
concept of history...


Johan Herland, <jo...@herland.net>
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

Reply via email to