3

I'm using svn2git to test the migration of an svn repo to a git. Now my svn is build like thise

myproj contains

repo1 /
repo2 (obsolete)/
old/

Every repo contains its own branches, tags etc. I only need everything which is in repo1. When I start the process I get this:

svn2git https://server/myproj/repo1 --username LVO

output:

Initialized empty Git repository in /folder/.git/
Using higher level of URL: https://server/myproj/repo1 => https://server/myproj

And than the process starts. I'm afraid it's taking all the other old repo's too. Is this the right way to start it?:

$ svn2git https://server/myproj/repo1 --username xxx --trunk=/repo1 --branches=/repo1 --tags=/repo1

(especially the trunk thing is not clear for me). How do I have to launch svn2git when my repo is in this tree.

DenCowboy
  • 10,114
  • 24
  • 80
  • 168

1 Answers1

7

For a one-time migration git-svn is not the right tool for conversions of repositories or parts of repositories. 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.

The svn2git tool you use is based on git-svn and thus suffers from most of the same drawbacks, only fixing some in the post-clone actions.

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.

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 svn2git that is based on it) 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. :-)

Vampire
  • 31,050
  • 2
  • 58
  • 88
  • There is another superior solution what might be more powerful than this one ;) http://www.catb.org/~esr/reposurgeon/ https://gitlab.com/esr/reposurgeon https://wiki.freephile.org/wiki/Reposurgeon (Linux only, currently GoLang, was a python oriented) – Andry Jun 19 '19 at 22:35
  • I don't see how that should be better. From what I've seen from a quick look, there is no added value. Only less features / control regarding conversion. And on their comparison page, they are not even comparing against this, just against some 10 years old or older forks or predecessors and for those they just write there is no documentation or examples so they are too ... to create a comparison. Which is actually all wrong and not very trust increasing. – Vampire Jun 20 '19 at 01:11
  • After a moderate research i've concludded that the author have made a real internal command language to cut and edit a serialized stream of a version control system exported data between many systems like cvs, svn, git and others. You can take a look for yourself: http://www.catb.org/~esr/reposurgeon/reposurgeon.html. It is much bigger than the rules from the KDE tool. – Andry Jun 20 '19 at 14:39
  • Bigger is not always better. :-D I've seen that page before, but didn't read it fully, as it is too much text currently. The KDE svn2git rules are simple but powerful and I didn't have a case yet, I wasn't able to handle with them. Besides that, can reposurgeon for example split one SVN repository into multiple Git repositories in one run? I needed this multiple times already and it is trivial with svn2git, I didn't see it for reposurgeon. Also reposurgeon cannot even handle paths only differing in case properly on some OS while svn2git has no problems at all with that.To just name two points. – Vampire Jun 21 '19 at 07:30
  • I agree with that it is much more complicated to research and start to use, but if you want a tool for greater svn/git streams introspection then this is the thing. I beleave it has a command to filter a branch or a path if you want to. I didn't search for it, because the both tools does not support svn externals and git trees as i would expect, and it seems more critical for me than other features. – Andry Jun 21 '19 at 20:51
  • But author states that the `reposurgeon` has been used to port many more repositories, when the KDE tool does used only for the KDE repositories as well which might be much more important for stable convertion of an average really big repository. What for me it can tag the commits with only external properties as empty commits, when the svn2git does not. – Andry Jun 21 '19 at 20:51
  • "greater stream introspection"? It is about conversion, not introspection. For introspection I use svneverever. Of course reposurgeon states that, but where is their proof? How could they know how many conversions are done with either tool that is freely available? And such statement is plainly made up and does again greatly decrease trust and increase disgust. I converted several really big repos with svn2git. About tagging empty commits, I'm not sure what you mean, but tagging empty commits should work fine. – Vampire Jun 22 '19 at 09:00
  • Btw. one other important point for me is speed. I don't know how fast reposurgeon is, but svn2git is super fast if you give it enough resources and a fast disk. Where git-svn would have needed maybe 2 months, svn2git converted in about one day a 10 year old repo with about 200.000 commits. But honestly, each one should use the tool he likes most, I'm just advising a more suitable one here with which I had very good experience when one uses a tool that is not really suitable for one-time conversion. – Vampire Jun 22 '19 at 09:05
  • The story of conversions you can find at the end of http://www.catb.org/~esr/reposurgeon/features.html. You have to learn the inner language to find out how it can be useful for you, this is it. I don't expect you want it. But this is the same story as for the svn2git, you have at least learn the rules in there too. Tagging in the git is a different thing than in the svn: https://stackoverflow.com/questions/22822020/convert-an-svn-repository-to-git-with-reposurgeon-without-creating-gitignore-fi. Which gives the idea that the conversion have to be controllable and manipulatable from outside. – Andry Jun 22 '19 at 14:12
  • You can not just run the conversion code and expect all would be fine. Especially for big repos. So there is an absolute need to manipulate the stream. Otherwise your repository won't be exact with the original. That's it. May be for small repositories this not the tool you looking for. – Andry Jun 22 '19 at 14:16
  • Well, that lists a few repos they know were converted with their tool, but there is still no data that can support a statement that their tool was used for more repos. Alone me, I used it for conversion of more repos than they list there. Tagging is not really different in both imho and you can control the conversion, that's what the rules are for. After such a conversion you will never have exactly the same as the original, but it needs to be sufficiently similar and for me it always was with `svn2git` and as I said, I converted some really big and old repos with it. :-) – Vampire Jun 22 '19 at 20:27