[Kde-scm-interest] meeting summary

[Oswald Buddenhagen]

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. ;)