Subclipse vs. Subversive, 1 year later
Almost a year ago I wrote about my initial thoughts on switching from Subclipse to Subversive, and it continues to be one of my most-googled posts -- not to mention that people encouraged me at the time to follow up later. I think it's about time.
Where are they now?
The first question is, of course, do I still use Subversive instead of Subclipse? The answer is yes... when I have to use Subversion at all.
To be honest, I've moved as much as is possible to Git -- even more than was true when I wrote my last entry. I mentioned at the time that I preferred using Git for my personal projects, for which I didn't have to worry about collaborators resisting the change, because there are no collaborators when working alone. But I spend more time working as part of a team (at work) than I do working on my personal projects, and 90.6976% of my work projects use Subversion. For a while I continued to use Subversive, and it got the job done, without the problems I experienced in Subclipse. Subversive is available through the official Eclipse Helios update site, which is probably an indicator of general consensus on the better option.
Then I started playing with git-svn, hoping I could make it work well for my needs. A few weeks later, a colleague on another team posted a blog entry about how he was using git-svn for his work projects. I guess that was what pushed me over the edge, because before his entry I was only using git-svn for 1 project, and after, I started using it everywhere possible.
Git-SVN
Git-SVN is a bridge baked into git -- not a separate tool you need to install -- that allows you to use Git as your SVN client. You can create a local copy (a git clone) of a subversion repository, use it just as you would any other git repository, and then push your changes back into the subversion repository when you're ready. The process is fast and painless enough to read from and write to your subversion repository all day long. In case it doesn't go without saying, this is tremendous.
There are lots of things to consider when working collaboratively using git-svn. The workflow choices are numerous and all outside the scope of this entry. But the important takeaway is that if you're a git-head, and I am, then most of the time you can use git-svn instead of Subversion.
When can't you use git-svn? The situation where I still find myself using Subversion, and thus Subversive, is when I'm working on a shared project on a remote development server and setting the project up to run locally would take longer than making the code changes. Not only would the setup be more onerous, but after pushing my changes back into the SVN repo, I would have to go run an svn up on the shared development server -- one more thing to forget to do. Other than those types of projects, I've been svn-free for several months now.
Take the plunge
Distributed version control is here to stay. DVCS isn't going to kill SVN, just as SVN didn't kill CVS, but if you want to work on distributed agile teams (for example, most modern open source projects), DVCS is the clear choice. It may be another flavour: Mercurial, Bazaar, etc; but the concepts should pretty easily transfer between them. In the long run, you'll be better off for having learned something new.
Published 2011-02-25 @ 04:30 in 6 Responses Git Subversion
This November I'm running a marathon to raise money for Children's Miracle Network. But instead of running a marathon I'll be playing an epic 24 hour video game marathon.