Not many people know this, but if you work for a draconian empire who insists on using Subversion across the board and won’t let you move to something a little better like Git, then there’s actually a tool just for this task.
Built into Git is git-svn:
TO WORK WITH AN SVN REPOSITORY BUT WORK WITH GIT LOCALLY:
git svn clone [http location of an svn repository]
Now you can work with the checked out directory as though it was a git repository.
TO PUSH (COMMIT) CHANGES TO THE REMOTE SERVER
git svn dcommit
TO UPDATE YOUR LOCAL REPOSITORY FROM THE SVN REPOSITORY
git svn rebase
NOTE: make sure you have your perl bindings to your local svn installation.
I screwed up, how do I reset my checkout?
git checkout -f
* Note, I don’t work for a draconian empire, and I use Git.
Having used Git and Subversion (and several other) versioning systems over the years, I’d certainly not classify Git as “better” than SVN. However, I’d rank both of them “better” than the system that’s currently used here.
Thanks for the tip, Neil.
I was actually thinking about this the other day!
What benefits are there with this process? You get the local git management of your code (branches, etc), while still keeping the SVN backend?
@Jim – Once you’ve done the clone, locally you have a Git Repo so can therefore do all the normal git stuff you would. You are essentially creating a git clone of an SVN Repo.
For me this means that you can branch and merge nice and easily, as well as commit offline etc (essentially the benefits of Git over svn
Using Git as a Subversion client | @neilmiddleton…
…
Nice post about using the git-svn bridge. Just a shame there’s no usable git gui (and no jGit/eGit is not viable – eGit by name and by nature).
I’d quite like to use git locally with the central repo of svn. There are times when it would be nice to have lots of little repo’s of test code locally without muddying SVN.
You just can’t have random repo’s floating about in a commercial organisation. You need to know where your source code is and be sure that its being backed up. git just does not give you that security. And no, cloning repos to every developer’s machine does not mean that your source code repo is backed up or secure. If you set up your own “git-hub” then you’re back to an SVN architecture, which is much mature and has the client tools to go with it. ~shrug~ why bother moving from SVN to git.
Nice post, though shame about the drivel in the first paragraph. I’m sure your employer and clients really appreciate being called a “draconian empire”
@Stephen I used to look at Git the same way, but then tried it out. If the one benefit of SVN over Git for you is the centralisation, then just set up your Git setup like that. Yes, it’s distributed, but there’s nothing to stop you from using internal policy to have a central repo that is considered the master (and that’s exactly what we do).
The power of git comes in it’s simplicity, and the lightweight branching and merging. For years I used svn and often had to really think hard about getting some hotfix into production while there was loads of other develoment going on. Git requires a lot less thinking up front, and let’s you get on with your work.
Lastly, wrt to my employers and clients aren’t “draconian empires’ – they are all lovely people, hence the note at the end of my blog post