What are the pros and cons of the --svn-branches parameter to svn2git

Question

I'm using svn2git (the good one) to transform some SVN repositories to Git repositories.
It has a commandline parameter --svn-branches which is documented with

Use the contents of SVN when creating branches, Note: SVN tags are branches as well

What are the pros and cons of this commandline parameter.

Is it just that without it is faster because there is just a Git tag created and not the whole work tree dumped and with it is safer to have the correct state because the whole work tree is dumped or is there more to it?

Would you recommend using or omitting this parameter?

Livery

Answer 1

The MoveToGit/UsingSvn2Git man page mentions:

The recurse action is a hack to tell svn2git to recurse into a directory it has just copied or that existed because it is of interest.
Example: if we are importing kdelibs, it exists in trunk/KDE/kdelibs. At branching, someone did:

svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4

SVN recorded in that commit that branches/KDE/4.4 was the only path changed.
That means the rule

branches/KDE/[^/]+/kdelibs/

will not match.

We need to tell the tool that something interesting happened inside and it should recurse. Then it will apply again all rules to the files that exist at that point, at which point the rules will match.

I suspect this option --svn-branches has to do with the "recurse action"

Hindorff

If this is the case, why is this not the default or only supported way of working? Not doing it sounds to me like you could easily get a wrong / unexpected result. So this should at least be the default behaviour, shouldn't it? – Livery

@BjörnKautler I agree, unless most of the time, a new SVN branch means additional files, and not deleted files. – Hindorff

Which then will be missing, won't they? As bad as additional files usually, maybe worse – Livery

@BjörnKautler No, if a new SVN branch only adds files compared to the previous revision, said files won't be missing when imported in a new git commit branch. – Hindorff

If the commit that added the branch also adds file, the branch will be correct, but if the commit that creates the branch also removes files the branch will be incorrect? That would even be more confusing and shout for making the behaviour mandatory – Livery

@BjörnKautler No, in git, creating a branch does not add or remove files. If the SVN revision that creates a branch also remove files, then the git commit created (as the first commit of the branch) will be incorrect. – Hindorff

Yeah, I know, but I don't see where the difference between added and removed files is then, as for both svn2git would need to create an additional commit as first commit in the branch to reflect those changes. – Livery

@BjörnKautler The difference is, without this option, the first git commit of the new branch will include extra files that were actually removed in the first svn revision of the branch exported. – Hindorff

Why would that be so and why wouldn't there be files missing if they were added in the first SVN revision? And more importantly, what the main question here is, if you get correct tags and branches with this parameter and potentially wrong ones without, why is it not the default behaviour and why is it an option anyway? There must be drawbacks when using the option, so which are they? – Livery

@BjörnKautler You are right. I suspect this option enables another feature of the svn2git import. I have added a possible relevant section of the manual in the revised answer. – Hindorff

I'm sorry, but I cannot grant the bounty for your answer, as I don't think it is right. Looking at the sources, --svn-branches is totally unrelated to the recurse action and your answer does not really answer my question. – Livery

@Livery No problem, I hope you will fond the answer. – Hindorff

Me too. I asked the developer who invented it, but he doesn't remember :-( – Livery