0

I am in the process of moving from SVN to git, and I am trying to migrate my existing SVN repository using the git svn wrapper, svn2git (https://github.com/nirvdrum/svn2git). I am using svn2git because it keeps branches intact. My end goal is to put the project onto github.

When performing the clone through svn2git, the execution halts when it tries to access a folder:

svn/https%3A

Which is supposedly a branch - however I cannot see it in the repository. I am assuming that at some stage I had accidentally named a branch beginning with https: (thinking it required the full SVN path), however now I am unsure how to remove it again because it cannot be found.

Is there some way to find and delete this using svnadmin?

user984976
  • 1,314
  • 1
  • 12
  • 21
  • does svn2git list a rev it's failing on? can you do a log on svn/branches and find it? likely it was created and deleted (hence it's not readily visible) – thekbb Feb 05 '13 at 21:02
  • Yeah.. it's failing on rev 789, I did grep on the svn respoistory on the server and found that revs 788, 789 and 790 contain traces of branches/https:/... My problem though is that I am unsure how to avoid these revisions when fetching? – user984976 Feb 05 '13 at 21:23

2 Answers2

2

After spending a number of hours on this, trying various methods for performing the conversion (I did not try thekbb's proposed solution because I had not seen it before I found an answer), I ended up ditching git-svn and going with subgit which converted the whole repository first time, without any hassles.

I don't want to get into hot water here by pitching one against the other, but I will say my experience with subgit has been far better than that with git-svn, or the wrapper, svn2git.

It seems that git-svn will throw an error when it encounters irregularities in the subversion repository, however subgit seems to sort it out itself, which I prefer in this case because I am migrating from SVN to Git, so any time I can avoid spending patching the SVN repository is time I am happy to save.

The only thing I didn't see listed in the subgit install guide (I may have missed it) was that you should take the svn server offline when performing the installation, otherwise you'll end up with 'Interruptions' (when someone accesses the repository) which stop the installation.

user984976
  • 1,314
  • 1
  • 12
  • 21
  • Thanks for your answer from SubGit dev team. I'd like to ask you what kind of interruptions did you experience? If you were using SubGit 1.0 then SubGit should install certain hooks into SVN and Git repositories to make sure that every revision was converted even if it was committed while the installation was in progress. So, there's no need to shutdown the server in this case. SubGit 2.0 EAP builds had some issues indeed; these issues should be already fixed in the latest version. – vadishev Feb 12 '13 at 09:50
0

It's been a long time, and I apologize for not testing this out... but in theory you could delete the offender with

git branch -D https%3A

and then restart with:

svn2git --rebase

If that doesn't work, I'd try using svndumpfilter to remove that branch. You'll have to dump the repository with svnadmin dump and then filter it:

svndumpfilter exclude branches/https%3A < dumpfile > filtered-dumpfile

Then you can load filtered-dumpfile to a new svn repo then do an svn2git on that.

thekbb
  • 7,668
  • 1
  • 36
  • 61
  • 1
    Hello, thank you very much for taking the time to reply to my question. Unfortunately I did not test your answer. Before it was listed I tried subgit instead (see my answer) and it worked without problem. However, I think the svndumpfilter is along the right lines for correctly 'fixing' the svn repo. Again, thanks for your time I really appreciate you trying to help. – user984976 Feb 06 '13 at 06:36