new Github repo history gets corrupted when an SVN project history contains a "fork" for a different version

[cromero-wincomplm]

We're using KDE's svn2git tool, (svn-all-fast-export), but we've noticed, that when a project, has been manually "copied/forked" during its history in SVN the resulting Github Repo will not be accurate comparing against the latest revision of SVN trunk.

What's the best way to implement project rules that can avoid this mistakes, currently we're using the following rules:

declare PROJECT_NAME=<svn project name>
declare PROJECT_PATH=/<starting path>/.+/<svn project name>

create repository ${PROJECT_NAME}
end repository

match ${PROJECT_PATH}/trunk/
  repository ${PROJECT_NAME}
  branch master
end match

match ${PROJECT_PATH}/branches/([^/]+)/
  repository ${PROJECT_NAME}
  branch \1
end match

match ${PROJECT_PATH}/tags/([^/]+)/
  repository ${PROJECT_NAME}
  branch refs/tags/\1
end match

match /
end match

Thanks for all the help that can be provided in this subject.

[eeijlar]

Are you saying that the 'forked/copied' project doesn't match any of the rules you have defined above? Can you provide the svn path to the 'forked/copied' project?

(I think you mean copied, I don't think svn has a fork option as far as I know)

[tnyblom]

My best advice would be to take a file that is inaccurate in git, trace it's history in SVN and then try to write rules that would match it's history. Doing this might give you a longer rule file but it will allow you to get 100% accurate conversion.

[cromero-wincomplm]

Thanks for the quick replies! I will test the proposed solutions!