7

I'm trying to convert an SVN repo over to multiple git repos. So far I have been using git svn clone svn_repo_project_path for each project in SVN. I have noticed that git does not seem to follow svn copy operations so the resulting history is much briefer than I expect. Suppose my SVN repo looked like this:

root

  • a
  • b
  • c
  • parent-proj
    • b
    • c

Projects b and c were recently copied under parent-proj as part of a restructuring effort with the intention of eventually deleting them from their old locations under root. When I do git svn clone http://svnhost/parent-proj the resulting git repo is missing all of the history that originated from /b and /c before the move.

Is this a limitation of git-svn or is there some way to get this history to show up in my repo? From my limited research it seems that using the filter-branch command as described in Getting complete history of an SVN repo that's been renamed using git-svn may work although in my case there are multiple parents which probably complicates things. Could cloning the entire repo first and then splitting out new repos from it (using filter-branch?) be a better approach?

Community
  • 1
  • 1
Patrick Marchwiak
  • 1,072
  • 2
  • 11
  • 24
  • I am getting blame history of all files even when they move directories. And my `git svn clone` also tracked projects outside of the directory being cloned (where they originated from). – Shadow Man Aug 31 '13 at 02:11
  • 2
    @ShadowCreeper: What version of Git were you using? I'm having the same problem as Patrick – Pylinux Oct 02 '13 at 20:02
  • I'm not sure which version they were cloned with. I believe it was originally a 1.7 release (it was a few months ago with the then-latest version from debian wheezy). However I recently recloned one of the projects with a messy history using v1.8.4 and it behaved the same (some SHAs are of completely different trees). Maybe the SVN server version is more important? I believe that is still on 1.7. – Shadow Man Oct 03 '13 at 06:38
  • 1
    Maybe you need a git refresher? I wanted to see the history of a function in my git repo (cloned using `git svn clone`) today, so I searched stackoverflow and came across http://stackoverflow.com/questions/4908336/can-git-really-track-the-movement-of-a-single-function-from-1-file-to-another-i which showed me `git blame -C MyFile` which gave me the blame history of the function I wanted all the way back to the original file (which was in a different directory) that this file was copied from (the original file still exists in the new directory today but those lines are no longer in it). – Shadow Man Oct 03 '13 at 23:55
  • Just got a look, they were originally cloned using git version 1.7.10.4, however I am now using version 1.8.4 (built from a clone of the git repo on github: https://github.com/git/git ) and the functionality in this regard appears the same. – Shadow Man Oct 04 '13 at 00:02
  • Also, I created them using `git svn clone -s svn://myserver/myproject` (note the lack of `/trunk`) in case that matters. – Shadow Man Oct 04 '13 at 01:43
  • One thing I have noticed is that if your SVN project was split into several smaller projects (`mainProj/trunk/module[AB]` into `moduleA/trunk` and `moduleB/trunk`) you will not get the history of anything before the split. But if your whole project was copied (`mainProj/trunk` into `newMainProj/trunk`) then you should get the full history. – Shadow Man Nov 12 '13 at 23:23
  • 2
    First things first: Does svn remember history before project copy correctly? Do `svn log` and `svn log --stop-on-copy` and compare results. – Patryk Obara Mar 04 '14 at 14:28

1 Answers1

0

You will not get pre-copy-to-parent-proj history for b or c if you git svn clone http://svnhost/parent-proj . git svn interprets your supplied base-path as the shallowest-point you are interested in ingesting the SVN commits for, making Git commits for the same. As the historical commits under b and c are outside of this path, git svn won't mirror them, so you won't have that history.

Take a look at the documentation for the git svn init --no-minimize-url option:

When tracking multiple directories (using --stdlayout, --branches, or --tags options), git svn will attempt to connect to the root (or highest allowed level) of the Subversion repository. This default allows better tracking of history if entire projects are moved within a repository, but may cause issues on repositories where read access restrictions are in place. Passing --no-minimize-url will allow git svn to accept URLs as-is without attempting to connect to a higher level directory. This option is off by default when only one URL/branch is tracked (it would do little good).

Since your clone command does not specify multiple branches (perhaps because you have a complex, multi-project or non-standard layout), git svn just clones commits involving that path and downwards. Shadow Creeper in comments used the -s or --stdlayout option, which can explain why some history was preserved for them.

If this is a one-off conversion (one-way move from SVN to Git), then you should probably clone the entire repository, then you have good options for moving things around in Git to look the way you want them to, including the establishment of historical branches and tags. If the motivation to run filter-branch is to save repository space, make sure that this is going to actually save you something, and that it is worth the bother. Git is very efficient with storage.

One final word of caution on expections of history-searching in the Git clone. Look for history on a file using git log -C --follow <file-path> and Git will typically do a good job of locating and providing you with a history incorporating renames and copies. Don't expect the same for directories, e.g. parent-proj/b. Git tracks blobs (files), trees (of blobs), commits and parent commits, but does not handle directories or directory-copies in the same way as SVN.

javabrett
  • 7,020
  • 4
  • 51
  • 73
  • You explicitly will NOT have "good options for moving things around in Git". Git handles file move considerably worse than svn. – Honza Jan 26 '21 at 07:46