On Thu, Dec 10, 2009 at 08:56:18AM +0100, Thiago Macieira wrote: > Maybe what we can learn from this is we can have a "rule-writing" > script that scans our history backwards, given a seed of information > (where our current repositories' branches are). > i have suggested exactly that months ago. i don't care whether it is an integral part of "the tool" or a second tool which needs to run first. speaking from experience with cvs2svn i tend to think that the second option might be actually more desirable.
fwiw, here's what i mailed the git-svn maintainer two months ago: =========== my idea to solve that problem seems rather obvious: before starting the import, find out how the project root moved, backwards from the HEAD. taking things even further, one could track moves/copies of subdirectories/files into the project (in kde that happens a lot when application code moves into the core libraries). to avoid "ghosts" popping up in historic revisions of master, one would add pre-move history on branches and represent the move into the project as a merge commit. of course, these branches could not be meaningfully checked out, but that's a non-issue by all practical means. =========== note that the last sentence relates explicitly only to single files or directories which originate from projects which continue to exist after the move of the code in question. you already know my opinion about physically moving entire projects. ;) _______________________________________________ Kde-scm-interest mailing list Kde-scm-interest@kde.org https://mail.kde.org/mailman/listinfo/kde-scm-interest
