On Tue, Dec 17, 2013 at 11:57 AM, Jakub Narębski <jnareb@xxxxxxxxx> wrote: > Martin Langhoff wrote: > >> On Wed, Dec 11, 2013 at 11:26 PM, Eric S. Raymond<esr@xxxxxxxxxxx> 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 -- Johan Herland, <johan@xxxxxxxxxxx> www.herland.net -- 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