Let’s just jump into it.
Using Mac OS X, first make sure you have the git core installed as well as the git-svn components. Unlike other version control systems, git is not one monolithic program but a collection of smaller utilities, and the Subversion conduits are a subset of these utilities. The git-Subversion utilities themselves depend on having the
Perl::Subversion bindings installed for Perl 5.
For the lazy MacPorts user, simply run:
sudo port install git-core +svn
This will install the git-core, the git-svn packages, as well as all the documentation for git and any required dependencies you don’t already have. Note that the documentation (man pages) is installed in
/opt/local/man, which may not be in your default
$MANPATH, so be sure to add that directory if
man git returns a “No manual entry for git” error.
Alternatively, if you don’t want to use MacPorts, you can download a pre-compiled Mac OS X binary that includes git, the git docs, and the git-svn package from the git web site that comes complete with a standard GUI installation procedure.
Next, initialize a new git repository that tracks a remote Subversion one. This allows you to work privately using git, but to collaborate with other people who are using Subversion. Running
git svn init svn://my.svn.server/path/to/svn/repo workingcopy
will give you an empty git working copy named workingcopy configured to use the remote Subversion repository at svn://my.svn.server/path/to/svn/repo. This step is analogous to the need to run
svnadmin create repo_db, to initialize a new repository database (where all the file versioning information will be stored). Unlike Subversion, git’s distributed database means that the working copy itself is also the location of the repository database, so there’s no need to deal with two filesystem paths anymore.
Next, change directory to your working copy, and run
cd workingcopy git svn fetch
to populate your new, empty git working copy (and repository) with all the files from the remote Subversion repository.
Now that you have filled your git repository with a lot of data,
.pack file). The
git-repack -a command is used to do this, and its manual page says:
Instead of incrementally packing the unpacked objects, pack everything referenced into a single pack. Especially useful when packing a repository that is used for private development and there is no need to worry about people fetching via dumb protocols from it.
According to some sources, this can turn a 353MB Subversion repository into 31MB of git pack. Say:
git repack -a -d -f Generating pack... Counting objects: 284 Done counting 4475 objects. Deltifying 4475 objects... 100% (4475/4475) done Writing 4475 objects... 100% (4475/4475) done Total 4475 (delta 1876), reused 0 (delta 0) Pack pack-a115c320ff9c9968248bd250bdfea3110d0f0c1a created. Removing unused objects 100%... Done.
to perform the compression. For even greater savings, increase the compression by stipulating a high
--window option, such as
git repack -a -d -f --window=100. (
--window defaults to 10—the higher the window, the harder
git-repack will try to compress your stuff.) This turned a 36MB Subversion repository in one of my projects to a 20MB git pack. As always, your mileage may vary.
Congratulations, you have transformed your old Subversion repository to a git repository. All that’s left to do now is to get to the coding. Perhaps start by making a local (cheaper than cheap!) git branch….
That was easy, right? Most things in git are, in fact, that easy. If you’ve never used other version control systems before, be grateful. If you have, you can breathe a sigh of relief. Still not convinced? Don’t take my word for it…ask Linus Torvalds (or Randall Schwartz).