This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Leveraging the flexibility of Git and security of Subversion
Unless you’ve been hiding under a rock for the past couple of years, then you’ve more than likely heard about Git, the Distributed Version Control System (DVCS). You probably have developers asking if they can use Git, since it is faster and is built to make branching and merging cheap and easy to use. As a project manager or decision maker, you may also need to evaluate other requirements, such as: a) you need to maintain flexibility in your repository layout using ACLs (for example you can set ‘read+write’ account on ‘/trunk’ for your release manager and ‘deny’ at some level, i.e. ‘/trunk/reallySensitiveFilesDirectory’) b) you need to take backups of your entire repository in one location, knowing you can safely copy your entire history off site, c) you need to store or work with binary files, which requires some type of locking mechanism to prevent collaborators from overwriting one anothers’ changes.
In these regards, Git’s permissions structure, which lacks the granularity of centralized versioning systems like Subversion, has limitations. With Git, you are limited to granting read or write access to users, but not to the sub-director level. There are efforts to improve on this, but at the moment, they lack the maturity of Subversion’s Access Control List (ACL) model. In addition, backing up an entire Git repository is difficult, since Git encourages solo (distributed) development with potentially disjointed segments spread over multiple sites, making it harder to backup *everything* with certainty. Git lacks a locking mechanism, which makes it difficult to work with binary files (Word and PDFs files, etc). Given there is no way to merge binary files (the case for both Git and Subversion), Subversion users rely on locking to prevent impossible merge conflicts arising when 2 people are trying to work on the same binary at once. In Subversion you can lock a file, do your work, and unlock when done.
Git-Subversion Hybrid Approach
One way to benefit from the speed of Git and security of Subversion is to use a hybrid approach. Git even talks to Subversion natively via the ‘
svn git’ command, which makes it easy to communicate back and forth between the two systems. One way to think of it is that the server side is Subversion and client side is Git, so all changes you make as a developer will happen locally in your local Git repository, then when you need to share your changes with the rest of the team, push them up the tree to the Subversion server using the ‘git svn dcommit’ command. Now you can leverage Git’s cheap branching and speed, but maintain all the enterprise grade features of Subversion. To illustrate, say I have a repository layout of the following…
/branch /src /bin /lib /secretstuff To illustrate, lets checkout a Subversion location from the server.
> git svn clone https://spiderpigdude.svn.cvsdude.com/myproject Initialized empty Git repository in /tmp/myproject/.git/ W: +empty_dir: branches W: +empty_dir: tags W: +empty_dir: trunk r1 = 5b406c33fe89223f1024495ab00e4932423e65db (refs/remotes/git-svn) A trunk/somefile.txt ... ... ... Checked out HEAD: https://spiderpigdude.svn.cvsdude.com/myproject r13 creating empty directory: branches creating empty directory: tags * Notice, the ACLs on the Subversion server prevent me from checking out the ‘secretstuff’ folder Make some changes, add files, delete files, etc.
> edit, edit, edit > git add file > git add . Save my changes locally
> git commit -m "my first commit, yay" Push my changes back to the central SVN server
> git svn rebase > git svn dcommit Pull down the latest
> git svn fetch > git svn rebaseThis process adds a few extra commands than if you were working in Git alone, but of course you could easily create a command alias or bash script to wrap up several commands into one. Using the Hybrid approach, I get the best of both worlds, including:
- Speed and cheap easy branching of Git
- Keeping my developers happy, now that they have Git
- Flexibility with repository security model using Subversions ACLs
- Guarantee that my entire repository history is backed up in one location with Subversion
- Flexibility when I want to work with binary files