However, Git has to check out each version, one at a time, and commit it individually. The test project has only about 75 commits and the codebase isn’t that big, so it takes just a few minutes. This runs the equivalent of two commands - git svn init followed by git svn fetch - on the URL you provide. Initialized empty Git repository in /Users/schacon/projects/testsvnsync/svn/.git/ Remember that if you’re importing from a real hosted Subversion repository, you should replace the file:///tmp/test-svn here with the URL of your Subversion repository: $ git svn clone file:///tmp/test-svn -T trunk -b branches -t tags
You’ll start with the git svn clone command, which imports an entire Subversion repository into a local Git repository.
Now that you have a Subversion repository to which you have write access, you can go through a typical workflow. Subversion has to clone one revision at a time and then push it back into another repository - it’s ridiculously inefficient, but it’s the only easy way to do this. You can then clone the code by running $ svnsync sync file:///tmp/test-svnĪlthough this operation may take only a few minutes, if you try to copy the original repository to another remote repository instead of a local one, the process will take nearly an hour, even though there are fewer than 100 commits. This sets up the properties to run the sync. You can now sync this project to your local machine by calling svnsync init with the to and from repositories. $ chmod +x /tmp/test-svn/hooks/pre-revprop-change Then, enable all users to change revprops - the easy way is to add a pre-revprop-change script that always exits 0: $ cat /tmp/test-svn/hooks/pre-revprop-change To follow along, you first need to create a new local Subversion repository: $ mkdir /tmp/test-svn For these tests, I created a new Subversion repository on Google code that was a partial copy of the protobuf project, which is a tool that encodes structured data for network transmission. In order to do that easily, you can use a tool called svnsync that comes with more recent versions of Subversion - it should be distributed with at least 1.4. If you want to copy these examples, you’ll have to make a writeable copy of my test repository. To demonstrate this functionality, you need a typical SVN repository that you have write access to. If you’re working with a team, and some are using SVN and others are using Git, make sure everyone is using the SVN server to collaborate - doing so will make your life easier. Subversion can have only a single linear history, and confusing it is very easy. Although you can easily do local branching and merging, it’s generally best to keep your history as linear as possible by rebasing your work and avoiding doing things like simultaneously interacting with a Git remote repository.ĭon’t rewrite your history and try to push again, and don’t push to a parallel Git repository to collaborate with fellow Git developers at the same time.
It’s important to note that when you’re using git svn, you’re interacting with Subversion, which is a system that is far less sophisticated than Git. It takes quite a few commands, so you’ll learn about the common ones while going through a few small workflows. The base command in Git for all the Subversion bridging commands is git svn. The Subversion bridge is the gateway drug to the DVCS world. It’s a good way to sneak Git into the corporate environment and help your fellow developers become more efficient while you lobby to get the infrastructure changed to support Git fully. This means you can do local branching and merging, use the staging area, use rebasing and cherry-picking, and so on, while your collaborators continue to work in their dark and ancient ways. This tool allows you to use Git as a valid client to a Subversion server, so you can use all the local features of Git and then push to a Subversion server as if you were using Subversion locally. One of Git’s great features is a bidirectional bridge to Subversion called git svn. It’s also very similar in many ways to CVS, which was the big boy of the source-control world before that. It’s the most popular open source VCS and has been around for nearly a decade. Currently, the majority of open source development projects and a large number of corporate projects use Subversion to manage their source code.
0 kommentar(er)
