As some may know, I'm doing some work for a rocking email archiving company in Denmark, so obviously, my source repository isn't local - or even in this country. Luckily for me, it's Subversion (rather than VSS or TFS).
Up until now, I've been using Git (with -svn) to manage my code. This has worked well, mostly. I can check in locally (and hold changes so I don't disrupt things like customer builds etc), have local history etc. All good. Some of the down sides are around how git-svn works on windows - it's slow, to say the least. With a patch from Josh Robb, it gets quicker, but still - a check in that takes maybe 1-2 mins in subversion takes 10-15 mins using git-svn, and maybe 5x that without the patch. To check out the whole source tree, with around 2 weeks of history (we have around 2000 revisions in subversion, I'm getting the last 100 or so), takes 8-12 hours, even if I'm on the same lan as the server.
So, I'm looking at what I need, rather than the accepted use of the tools. I was reading this very entertaining post by Rob Conery about using Git as a backup client, and I've come to the conclusion that I dont really need git-svn. I need svn and git.
I have two distinct "methods" of working. For my own stuff, I have a remote subversion repo at dreamhost. I use this as an offsite backup for my code, as well as a nice, big undo button. I'm the only developer on this, so I can chop and change between tech here as I like.
The other case is the work with ComArchive. I can't change the back end (tho we did move from https to http, which sped things up a lot too), but I can do whatever I like on the client end, as long as it works and doesn't break others. But the main drivers here are that I need to work within the timeframes of the main team (aka Thomas), and I need to make sure my code is backed up incase my VM frys itself. Also, chewing up a work day getting the code down isn't really viable.
Case 1: Moving my personal stuff to git
This one is easy. Just export from subversion to a local folder, then git init / git add . / git commit, setup a remote git repo on my dreamhost hosting, and push to it. This is well documented pretty much everywhere - it's normal git processing.
Case 2: Using git as a backup and versioning tool for a local subversion working folder.
This one is not quite as obvious. Git's main focus is on versioning a set of objects (usually files). A subversion working folder is a set of objects.
So at the top level, I've just made a git repo, added all the files in the subversion repo into it (including the .svn folders), committed it, and then pushed it to the remote folder, just like I would with any other git repo.
git init
git add .
git commit -am "message"
git remote add backup git-url-goes-here
then, when I want to push out of the building:
git add .
git commit -am "message"
git push backup master
When I need to, I can just do a subversion commit to push back into the main repository. Git is none the wiser - it's just a bunch of files. Subversion, more importantly, is none the wiser.
This way, I can use subversion for what its good at - being able to work with just the tip locally, and pushing and pulling things very, very quickly over the wire. And I can use git for what it's good at, too - a local versioned repo, an offsite backup I control, branches (maybe) etc.
Win win. I hope.
I'm actually wondering if I start using git more as a backup tool. I have a load of business stuff that needs to be kept safe. It doesn't change often, but if we lose it, and get audited by HMRC, we're screwed (the whole "keep stuff for 7 years" thing).
Is anyone else using git like this?
