- My subversion repo is on another server so when I commit, I'm also backing up. Git does commits really fast, but only because everything is happening locally until you push (I think). I'd end up committing, then pushing every time to maintain my 'backup', so I presume the Git speed advantage would be lost...?
- Subversion was designed to be a better CVS, and I already knew how to use that, so switching to Subversion was easy for me. I believe Git has a bit of a learning curve?
- I'm not working in a huge distributed team so wouldn't benefit from Git's more sophisticated branching/merging/rebasing (whatever that is).
- Subversion has better clients: e.g. how sexy is Versions? It's also integrated into Coda. Git support/integration is gradually appearing, but it's not widespread yet.
- My Brightbox VPS came reconfigured with Subversion support. To use Git, I believe I'd have to install something like Gitosis...?
- Git is difficult on Windows (or was). Wait a minute, that's a plus point for Git!
RedFurSnake
Friday, May 29, 2009
Why Subversion?
Despite all the more interesting links in my last post, my use of Subversion was the only one that sparked any interest, so I thought I'd explore my reasons for sticking with Subversion, despite the current Git frenzy:Don't get me wrong, part of me wants to switch to Git, perhaps just because it's the latest greatest thing. On the other hand, I can't really see how it improves things for me. Feel free to convince me to switch to Git, or defend Subversion, or recommend something else (Bazaar, Mercurial?).
Subscribe to:
Post Comments (Atom)
9 comments:
Unless you plan on checking in lots of large binary files and updating them frequently, then Mercurial gets my vote. I've been playing around with it for a while - I need some sort of SRC system for managing changes to my websites.
Some hopefully compelling reasons:
1. The directories are not littered with .cvs/.svn files. (So Eclipse can't do hideous things to them).
2. It's distributed. CVS is not. Having recently experienced the effects of an entire team of developers being without a connection to the CVS server, I can say with great certainty, this matters.
3. It is *much* more simple than Git (which has a scary amount of commands), generally faster and doesn't require the extra maintenance that Git does.
4. It has a really cool name (if it was good enough for Shakespeare) that reminds me of my two favourite descriptions of people that I've ever heard, "Mercurial" and "Gelatinous".
@JoJo: All interesting... I'd love it if you would look at Bazaar too, and see how that compares. It has a much nicer web site than the others and appears to put more emphasis on ease of use: looks like it's trying to be the Mac user's choice...
Unfortunately, given my own requirements, you haven't given me any compelling reasons to switch:
1. The .svn files don't affect me (because I don't use Eclipse?)
2. I don't need the distributed features (in fact, they are a disadvantage, given my Subversion = backup philosophy).
3. Subversion is simple enough for me.
4. What's in a name? (But Git is admittedly, pretty much the worst name anyone could have come up with, as in "Yeah, my SCM system is a complete git". Maybe that context is a uniquely british thing?)
@Chris: I might have a look at Bazaar; I'm planning on doing things properly with my new site and so now have to set up some sort of SRC system.
1. Surely your directories should be just that, yours? Hidden files all over the place is not a clean solution, akin to the difference between RoR and C++? Also, trying to copy your files around when these hidden files are lurking everywhere can be very dangerous (again, my own experience is testament to this).
2, 3. If you don't need a distributed system then Subversion is probably good and simple enough for your needs.
4. To truly understand my fondness for the word Mercurial you would need to know about The legend of Jo Huh and Joe Way.
@1. Are you in control of your server and can you guarantee 100% availability? For us, working from home or at a customer site is a much nicer experience when the central repository isn't available - I can commit often and don't have to store up many changes until the central repository is back online. Although you get to 'commit' in SVN and git, I think pushing in git is more analogous to committing in SVN (and CVS).
@2. True, there is a bigger learning curve, but we are all intelligent people. For me, getting to use the features of git (or DVCS in general) outweigh the learning curve.
@3. DVCS features *may* benefit even just you. I don't know your development processes, but say for example you want to develop a couple of features, you can use 'local' branches to develop them independently of each other, then merge, test, and push them when they're complete. You can abandon a local branch that didn't work out, and that wouldn't "pollute" the central repository. Gone are the days of "you're only allowed to commit working code" - you should only *push* working code to the master branch, but are now free to commit whenever you desire. With frequent commits you have a better chance of rolling back only as far as you need to go when things go horribly wrong.
@4. I have to agree with you there. GUI clients for git are few and far between. There is gitk and git-gui which (at the moment) suffice for me. GitX ( http://gitx.frim.nl/ ) looks to be a nicer gitk for OS X. I'd be interested if Syntevo ever released a SmartGit product. But each to their own. I'm quite happy using command line tools as well.
@5. Fair enough - if your hosting company provides SVN support out of the box, then it would make sense to use it. I suspect at the time you chose your host, providing git support was rare, if not impossible, to find. Many more providers are supporting git (and others) these days.
@6. Not so. http://code.google.com/p/msysgit/ provides a simple installer and git shell, with gitk and git-gui. Granted, performance is not as good as unix/linux but that is down to the crappy Windows filesystem API, not git itself.
For us, it was a close call between git, bzr and hg, but we ending up choosing git simply because one of our employees has plenty of git experience.
@JoJo: so, git has a scary number of commands? You don't have to learn them all - and indeed, you don't need to. The commands are split between plumbing - the low level commands - and porcelain - high level commands based on the plumbing.
@JoJo: I agree with you about the CVS and .svn directories being a pain. None of that with git, bzr and hg.
@Chris - you can use a git front end with a subversion repository if you don't want to commit to a total switch. Googling for 'git subversion bridge' or 'git-svn' should give you loads of resources.
I suppose it was unlikely there would be any compelling reasons for me to switch to Git (or other DVCS) since I don't have any issues with subversion. and if it ain't broke... To be honest, I thought CVS was OK too (apart from file/folder renaming perhaps).
Until I have a huge distributed team, or the client tools and tool integration catch up, I think I'll stick with Subversion. It's not as if Subversion is finished anyway, e.g. with version 1.6, I believe it gets something like git's rebasing (although I still don't know what that is!).
One last thing Steve: how can you be in a (many month long) transitional state between CVS and Git? Surely you're either using it or you're not? I guess the issues must be with the iMS script, otherwise you'd just have typed git-cvsimport and off you go!
@Chris - some of our newer work is maintained in git repositories, older work is still in CVS; we're running the two side by side.
The main issue with git is document management - tagging individual files ISSUE-1, ISSUE-2, etc. just doesn't work on a non-file based repository (SVN included).
And, yes, the iMS script is a big stumbling block as well. We don't want one mahoosive repository with everything, and we're trying to work out the best way to split it up.
If you're using subversion as just a backup tool, I'm not surprised you can't find a compelling reason to switch. (We thought CVS was simple enough for us, but there are plenty limitations and git frees us from those.)
@Steve: it must be a nightmare running both Git and CVS together, e.g. how to you share common libraries? Are they committed to both or is there a way of linking the two?
Perhaps you don't need to tag documents that way. I know we thought it would be useful when the iMS script was conceived, but I'm not sure the tags were ever used. The main thing was that a release (or branch) held the pertinent versions of documents, which wasn't always the latest version.
When the iMS script is rewritten, it might be an idea to make it SCM agnostic (and rewrite it in Ruby of course!)
I'm not using Subversion only as a backup tool: I tag my releases and have previously had to branch a release to do some emergency patching, etc.
SmartGit beta @ Syntevo
Post a Comment