Exclude deleted svn branches/tags on migration to git (git-svn)

Question

I'm currently migrating a huge repository with a long history from SVN to git. The svn repository has many branches and tags. I've cleaned up a lot of them from the SVN repo, but when I use the git svn clone command, it clone all the deleted branches and tags as well.

Question is, is there an efficient and easy way (simple command) to exclude fetching deleted branches and tags with git svn or svn2git (or any other tool for that matter)?

Tree

I haven't done any svn-to-git migrations so I'm not sure what the answer is, but I will say that the reason why it's including all of those deleted branches and tags because it's preserving the integrity of the repository. Even though those branches/tags are deleted from the latest revision, they still exist in the repository. Therefore, this dump you're trying to do is including those revisions. Does svn2git or git svn have any commands in which you can specify revisions? For example svn2git -r 1:72, 79-100 effectively skipping revisions 73-78? – Silverweed

@Chris, yes! AFAIK you can give git svn a starting and ending revision but not skip revision in between. But even if that would be possible, it would be quite a job to list all the revisions to skip. So that wouldn't be an option for me. – Tree

If you don't have filesystem access to the main repository and can't afford to run svnrdump, you're left with the --{in,ex}clude-paths options on git svn fetch (and …init, and …clone). The docs for those give examples of how to specify what you want to take and/or exclude, is there some specific problem with that? – Brahmaputra

@Brahmaputra Think of a use-case where you want to migrate a svn repo containing 1000 deleted branches (what I am currently working on). You would need a minimal script in order to exclude all the deleted branches from the migration. – Valdovinos

Answer 1

TL;DR: Yes, if you use the right svn2git tool

---

For a one-time migration git-svn is not the right tool for conversions of repositories or parts of a repository. It is a great tool if you want to use Git as frontend for an existing SVN server, but for one-time conversions you should not use git-svn, but svn2git which is much more suited for this use-case.

There are plenty tools called svn2git, the probably best one is the KDE one from https://github.com/svn-all-fast-export/svn2git. I strongly recommend using that svn2git tool. It is the best I know available out there and it is very flexible in what you can do with its rules files.

You will be easily able to configure svn2gits rule file to produce the result you want from your current SVN layout, including any complex histories that might exist and including producing several Git repos out of one SVN repo or combining different SVN repos into one Git repo cleanly in one run if you like and also excluding any paths or branches or tags you don't to have migrated, though I'm always crying a little if someone discards code history which is precious.

If you are not 100% about the history of your repository, svneverever from http://blog.hartwork.org/?p=763 is a great tool to investigate the history of an SVN repository when migrating it to Git.

---

Even though git-svn or the nirvdrum svn2git is easier to start with, here are some further reasons why using the KDE svn2git instead of git-svn is superior, besides its flexibility:

• the history is rebuilt much better and cleaner by svn2git (if the correct one is used), this is especially the case for more complex histories with branches and merges and so on
• the tags are real tags and not branches in Git
• with git-svn the tags contain an extra empty commit which also makes them not part of the branches, so a normal fetch will not get them until you give --tags to the command as by default only tags pointing to fetched branches are fetched also. With the proper svn2git tags are where they belong
• if you changed layout in SVN you can easily configure this with svn2git, with git-svn you will loose history eventually
• with svn2git you can also split one SVN repository into multiple Git repositories easily
• or combine multiple SVN repositories in the same SVN root into one Git repository easily
• the conversion is a gazillion times faster with the correct svn2git than with git-svn

You see, there are many reasons why git-svn is worse and the KDE svn2git is superior. :-)

Megavolt

Thx for the detailed description. The KDE svn2git is quite different from what I use (nivdrum svn2git). The KDE tool is a server side tool while nivdrum's is a client side which is using git-svn underneath (with some extra scripting). The KDE tool is out of question because of it beeing server side. So I'm left with nivdrum. But from your response, I still don't have a clear answer to my question, therefore not accepting it. – Tree

Yes, nirvdrum svn2git is based on git-svn and as such the same I wrote applies to it. It works around some of the drawbacks of git-svn, but by far not many and the result will still be sub-optimal. The KDE svn2git is NOT a server tool. You can run it wherever you like, I used it on server, on client, on Linux, on Windows, doesn't really matter. It might be a bit more performant on Linux though. The only requirement is, that you have a copy of the repository files. If you don't have access to the files on the server you can still use rsvndump or svnrdump to get the files you need. – Megavolt

Ok thx for the info. What I meant with "server side tool" was that in needs to access the filesystem where the svn repository is. I were not aware of the rsvndump and svnrdump. Will look into them. Thx again! – Tree

I tried the svnrdump to be able to use KDE svn2git on my machine. I queried for 1000 revisions back and only trunk. Had to stop the execution after 12 minutes since the diskspace it took was about 1 GB and I will need to fetch 120000+ revisions. It could take quite long time to fetch everything. So then I'm back to square one. :( – Tree

Well, then I guess the answer is no then. Maybe try rsvndump whether it needs less space? – Megavolt

This does not really answer the question. How do you avoid importing deleted svn branches with svn2git? By specifying the branch of each name in the exclude-path option? This does not scale very well for a repository with thousand branches.. – Valdovinos

You can for example use svneverever to analyze which branches are gone and then build rules for parameters for the tool at hand. – Megavolt