7

Possible Duplicate:
How to git-svn clone the last n revisions from a Subversion repository?

I am trying to move my WordPress Plugins which are hosted in the massive WordPress Plugins repo to Git.

I tired using git-svn and it is taking too long (more than 4-5 hours for a single Plugin) and I have close to 20 Plugins to migrate.

I have the checked out SVN repo on my machine. Is there any way by which we can import the SVN repo into Git by just using the history information stored in the .svn folders without connecting to the SVN server?

Community
  • 1
  • 1
Sudar
  • 18,954
  • 30
  • 85
  • 131

3 Answers3

8

You don't have the SVN repo on your machine. You have a working copy.

Unlike Git, SVN doesn't download the entire repository, with the whole history, when checking out a working copy. It just downloads the latest versions of the files.

So no, it's impossible to get the history of an SVN project from a working copy.

JB Nizet
  • 678,734
  • 91
  • 1,224
  • 1,255
  • hmm... I kind of know it, but still wanted to confirm. It seems using `git-svn` is the only solution now :( – Sudar Dec 29 '12 at 16:51
3

TL;DR

No. However, you have some alternatives.

Git and SVN History

The way Git and SVN handle history is completely different. When you check out an SVN repository, the .svn directory only holds the most recent commit so that it can be compared to the working directory or reverted.

Git, on the other hand, clones the entire history. There are certain exceptions such as shallow clones, but for most purposes Git will require a complete repository to do things like showing history or calculating diffs.

If you don't mind a truncated history, you can look at the --depth or --revision flags for git-svn. These flags will allow you to limit the number of revisions you retrieve from the SVN repository, trading history and functionality for speed.

However, while you could import your SVN working copy as a new Git repository, the .svn directories don't hold any actual history. You must connect to the SVN repository to access the history, so you can't import from a working copy.

Mirror Subversion First

However, you might consider mirroring the Subversion repository and then running git-svn locally against your mirror. You will still need a complete copy of your SVN repository, but mirroring the repository takes less time than retrieving Subversion commits one at a time over a network connection with git-svn.

Note that you still can't do what you want, but this is another viable alternative to improve the speed of SVN->Git migrations. In addition to a speed boost, this will also result in a more-complete history on the Git side.

Todd A. Jacobs
  • 81,402
  • 15
  • 141
  • 199
1
  1. .svn dir in Working Copy does not contain full history of repo, only "pristine copy" of data in WC (and some additional metadata) - you will not be able to get full history without interacting with repo
  2. If you want finish process faster, you can try to do it, for the cost of local disc-space

Suggested workflow may be something like this:

  • Get local (file:/// reached) SVN-repos, separated by plugin (one plugin - one repo). This way you'll get (on conversion stage) fastest access to source data and unnecessarity of filtering commits from unrelated (for processed plugin) parts of the repository. Use svnadmin dump| svndumpfilter of svnrdump | svndumpfilter for preparing cleaned dumps. Probably, one full svnrdump and filtering it later cat DUMP| svndumpfilter include fill be even more time-efficient;
  • Import into Git small repos, prepared in previous step.
Lazy Badger
  • 94,711
  • 9
  • 78
  • 110