Why You Should Switch from Subversion to Git

http://carsonified.com/blog/web-apps/why-you-should-switch-from-subversion-to-git/

by fogus • 17 years ago

44 75 17 years ago

carsonified.com

axod10• 17 years ago

Jesus christ. The amount of time people spend blogging about how great git is could be surely put to better use.

It's just a linkbait headline. Use whatever fits your usecase the best.

For me to switch from svn to git, I need to be experiencing pain using svn. I don't feel any pain :/

Of course if I'm working on a project in the future that looks like git may help, I'll look at git and see if it'd be more appropriate than svn...

Wish people would quit with the "Tool X is always better than Tool Y".

leftnode• 17 years ago

I'm not sure why you were downmodded, but I upmodded you because I agree. I use subversion daily, and I love it. I've dabbled in git, I understand the strengths, but for me, its not worth spending the time to migrate all of my projects over there.

RyanMcGreal2• 17 years ago

http://www.simplisticcomplexity.com/2008/03/05/cleanly-migra...

FooBarWidget5• 17 years ago

I didn't experience pain either... until I used git for a while. Then I realized all the pain that I was suffering but wasn't aware of.

> The amount of time people spend blogging about how great git is could be surely put to better use.

Maybe they're spending so much time blogging because git really is that good?

axod10• 17 years ago

How can you not be aware of pain? If I was wasting time on a laborious task, I think I'd know about it and think of a better way. Care to share an example from your experience?

During my average day, I probably spend a few minutes total messing with svn. For my usecase, it's already optimum. The only way I could reduce that time is to not put in any commit messages :/

durin424• 17 years ago

> Maybe they're spending so much time blogging because git really is that good?

That may be, but they're the only community I see being extremely in-your-face about their tool and how it's clearly beating the pants off everything else. Personally, I'd be more interested why they feel the need to declare its goodness so loudly, when if it really is as awesome as these articles make it sound then it'll spread like wildfire by word of mouth.

emacs changed the way I write code, and made me wildly efficient compared to before I used it. That doesn't mean I'm going to go and start browbeating people into using it. The git community seems to be blind to the notion that git (as wonderful as it is) might not be for everyone.

ebishop• 17 years ago

While I can understand how git is better for the majority of use-cases, I found that it was far less suitable than SVN for what I want to do. I used git for a while (3-6 months) and then switched BACK to using SVN. It's true I didn't experience pain until I started using git. That's when the pain started.

First, as I said, my use case is highly non-standard. I'm the only developer on my project, so I don't have to worry about collaborators. I do my work on a lot of different computers, so it turns out that (for me) one of the biggest advantages provided by version control is effectively synchronizing source code between systems, many of which get erased (e.g. new OS installed ) on a regular basis, all of which have internet access. It is important that I be able to quickly and simply set up a development environment on a new system -- a somewhat unusual requirement, I realize. Under these circumstances the primary advantage -- not just of git, but any DVCS -- becomes a major disadvantage. The whole point of DVCS is that the ability to commit is separated from the ability to update the central repository (git push), where they are the same in centralized VCS. However... I ALWAYS want to push when I commit. If I commit to a local repository on a machine that gets wiped, it does me no good. It needs to get updated in the central, online repository every time. This can be done with a short simple shell script, of course, but remember: I need it it to be as simple as possible to set up a new development environment. This adds an extra step, and if I neglect it, I can lose a lot of work. If I use SVN, I simply don't have to worry about it. It's automatic.

Another feature of SVN that I like, that's impossible with DVCS: revision numbers. With SVN, revision numbers increase sequentially from 1 to whatever number commit the last one was. DVCS can't do revision numbers because you can't determine the sequence of commits until after the commits are made (everyone has their own repository!). Being able to refer to r378 is a LOT nicer than referring to an arbitrary hexadecimal identifier. Having commit identifiers that convey information is a huge plus.

For me, these reasons are enough to outweigh the advantages of having access to repository history while offline and the better handling of branching that git offers.

oscardelben• 17 years ago

The article is indeed for people who are pretty satisfied with svn. I don't think of the article as a waste of time because there are many people who don't know what are the advantages of git over svn.

RyanMcGreal2• 17 years ago

To borrow a concept from programming languages, svn is blub.

axod10• 17 years ago

That's about as good an argument as saying only communists use svn.

So basically your argument is that the only people who can have a valid opinion about the usefulness of different rcs's are those using git :/

compay6• 17 years ago

I'm also surprised people are still arguing about this. I switched to Git so long ago I sometimes need to look at the man pages for SVN when I use it because I've forgotten how to do some things. IMHO unless you have a good reason to use SVN, you really should be using some kind of DVCS. SVN compared to Git/Mercurial/etc is like nano compared vim or emacs.

I do definitely consider "I'm already using SVN and I'm happy" to be a completely valid reason to use SVN because people should be free to use what they like.

But if that is your line of thought, keep in mind that you are making a concious decision to continue with a much less powerful tool and are not taking advantage of something that, if you put the time into learning it, would benefit you.

axod10• 17 years ago

Still generalizing IMHO.

Nano fits a whole raft of use cases. For a lot of things, it's better and more suited than vim or emacs.

Similarly, a whole load of use cases, svn is more suited to the task at hand than git is.

statictype• 17 years ago

Serious question:

What benefits would a single developer working in isolation derive from using a distributed version control system?

And what if that developer was running an OS like Windows? Does git have first-class support for Windows?

Would such a developer still see any advantage to using git?

mechanical_fish• 17 years ago

I don't feel any pain.

Have you asked your colleagues if your use of svn is causing them pain?

Or maybe you don't have colleagues. If you don't, that's fine. I used to work mainly by myself, and back then I thought as you do. Live and let live, I said. Choose the tool that works for you, I said. Hell, use CVS if you really want to, I said.

But now I work at a company that uses svn. And my coworkers' lack of productivity is also my lack of productivity. Every week or so there's some annoying issue: Programmer A doesn't commit the fix right away, because they made that fix in the middle of some other set of changes that would otherwise break the build, and they don't want to take the time to disentangle things. Programmer B commits to Branch Q, which is bad because the third-party svnmerge tool has been set to pull from Branch P to branch Q and not the other way around. And that's assuming there is a branch Q, because even with svnmerge everyone is scared to death of making branches. It's just so painful to reconcile them later.

So ultimately you have to make a choice: Are you going to sit around and allow your colleagues to waste time on your team's behalf? Or are you going to try to raise the bar a little by forwarding them an article about a tool that might solve the team's problems? Or are you going to quit and get a job with a company full of people who care about their tools?

P.S. For the record: Everyone at my own company is well aware of git, and bzr for that matter. But you're right: There are more urgent things to do in life than tinker with your VCS, so switching isn't a priority. And, as others will point out, there are little things about SVN, built up during its decade-long history, that haven't made it into git yet, and one of those might be a showstopper. So we may be gritting our teeth for a while yet.

doty2• 17 years ago

How does git make programmer A want to disentangle the fix?

How does git keep Programmer B from making changes against the wrong base? (Admittedly, git may make it easier to move that fix from the wrong base to the right one, but it doesn't make it harder to make the mistake; if anything, a prolifiration of branches an independent lines of development makes it easier to make that mistake, not harder.)

How does git make merging easier? Doesn't it do a traditional three-way merge, just like svn? And it seems like in DVCS you have more merging, not less...

CaptSolo• 17 years ago

One could also use SVN and GIT together. That might solve a part of the problem with not submitting fixes because of being in the middle of other set of changes. Develop using GIT locally and submit to SVN repository when ready.

What is experience of HN readers with using a combination of centralised and distributed VCS together? Have you used it and in what situations, if any, is it useful?

steveklabnik7• 17 years ago

> Wish people would quit with the "Tool X is always better than Tool Y".

Most of the time, I would agree with you. In this case, DVCS is a superset of VCS, so it is _always_ better.

sid03• 17 years ago

Centralized VCSes can lock files. DVCSes cannot. Ergo, DVCSes are not a superset of centralized VCSes.

doty2• 17 years ago

A superset is not always better.

Consider domain-specific languages vs. general-purpose languages. You need to weigh the benefits of increased power with the drawbacks of additional complexity.

DanielBMarkham• 17 years ago

Hear hear!

Versioning is about 1/10th of software engineering, and it's about 1/1000th of running a successful startup.

I wonder how many companies managed to survive in the bad old dark ages before we had git? </sarcasm>

This incessant cheerleading is obnoxious. Source control is simply not that much of a time sink (or shouldn't be) to warrant all this attention.

Work on making something people want, folks. Stop getting all wrapped up around the axle about some nifty new wizzbang tool.

uuilly2• 17 years ago

I just moved from a 4 man svn project to a 4 man git project. It took me a month before I didn't feel like an ass in git. I'm still not sure what I have gained. I know git is so powerful and does so many things, but I'm a simple user. To me version control is like a doormat: I pass it really quickly on the way into the house. If that's what it is to you git will not open up a new world. In fact it will just take you longer to become proficient and waste time that could otherwise be spent coding.

jerf3• 17 years ago

When you say you are a "user", are you not a programmer? If so, then you probably won't see much to be excited about.

If you are a programmer and you aren't seeing how source control helps you (and it sounds like you weren't seeing any particular benefit with SVN either), then you either don't have much experience, or are dangerously close to being the type of programmer who repeats the same year ten times, rather than acquiring ten years of experience. You really need to work on internalizing what source control allows you to do, git, svn, or otherwise. Not knowing what source control is good for is like a furniture maker wondering what a lathe is good for, beyond turning a simple cylinder. (Among other things, if there was a Furniture News, that's not the sort of comment that ought to be getting upvotes...)

Edit: Yes, nothing scores downmods like telling people that you need to know things to be a good developer. Guess what? You need to know things to be a good developer. Knowing what source control is and how to use it effectively is one of them. Downmodding me won't make that go away, nor will it magically make people who don't "get" source control better developers.

weaksauce2• 17 years ago

In interest of a full comparison does anyone have a link to an article discussing the reverse topic of why subversion is better than git? Does such an article even exist or is git that much better than subversion?

ohhmaagawd• 17 years ago

SVN has HTTP auth. no SSH key BS. Until Git has this you can forget about adoption for most corporate dev.

thorax• 17 years ago

Here's one take, though it's not wildly convincing:

http://blog.assembla.com/assemblablog/tabid/12618/bid/7437/W...

My job in the past was to evaluate source control systems for different organizations and what made the most sense. While I think Git and Mercurial are great for open source pieces, I'd pretty much never recommend Git inside of a large organization just yet. Perhaps never given how much visibility and control most companies want on their internal development flow. Checking in code to local repositories on any large scale isn't something most companies are big fans of.

Overall, Perforce is probably my most recommended for companies, though it has its downsides. Subversion with their improvements to branching should be getting more props these days, though. ClearCase is preferred by a lot of process-focused software companies (government contractors, etc).

What I think traditional centralized systems need is a better story for local repos or at least private branches. It needs to feel natural and built-in so that smaller pieces of work can be handled quickly without necessarily shipping them to team branches (or main). It's all doable now but the emphasis and infrastructure should encourage incremental changes in isolation which Git and Mercurial do a great job of. This feature isn't one major organizations need as an essential, but developers sure know the importance of it.

brutimus• 17 years ago

I've never seen such an article and in my own personal opinion, I don't see how such an argument could be made. I'm not a fan of Git in particular, but I love the "distributed" in DVCS. I use BZR on a daily basis and have never once found anything I missed from the days all of our projects were in SVN. You can use most of the DVCS tools just like SVN if you want (checkout, update, checkin), or go all out distributed with branches, merges, pushes, pulls, etc.

I guess SVN gives you real Trac support. :-) There are Git, BZR, etc plugins for Trac, but they all feel very hacked in and incomplete to me. I love BZR because it gets you launchpad.net (and it's got some stellar Py-bindings). I know Git has github, but I don't care for it either as a real project management suite.

EDIT: (Note: My opinions are from an open source developer perspective.)

ghempton• 17 years ago

You should checkout http://www.redmine.org/. Not only does it have real git support, but I much prefer it to Trac.

durin424• 17 years ago

The big failing of DVCSen is that you lose the ability to do fine-grained ACLs on code. For example, if a company wants to restrict access to certain parts of their codebase (eg, megacorp brings in contractors, they should see only the one tiny part of the code they work on), you can do that in svn, whereas with git you can't give them access to part of a repository. Heck, you can even integrate your ACLs with Active Directory if you have enough LDAP/Apache config fu.

Also, it makes pointy-hair types more comfortable to have a central server where everything is obviously canonical.

I don't think DVCS will ever fully supplant centralized systems (including Subversion, Perforce, and whatever else people use these days) in the corporate world.

defunkt• 17 years ago

You can do ACL with a DVCS by way of a pre-receive hook. It's just a matter of time before tools make this dead-simple.

weaksauce2• 17 years ago

Is it possible to pull out a portion of a project and then serve that as the canonical branch for the contractors? After the contractors git to their hearts content, could someone blessed to commit to a "master" then push only those changes or is that something that will not work?

I haven't used much git but they tout it as a very flexible system so I am wondering if it is flexible enough to accommodate this type of constrained work flow.

AndrewDucker2• 17 years ago

Not until there's an SCC provider for integration with Visual Studio. You're not going to get many of the coders in my company using the command line (or third party software) to check code in/out.

olliesaunders• 17 years ago

That's a shame. The shell is great, once you know how to use it.

AndrewDucker2• 17 years ago

Sadly, that's the problem - it's yet another thing to learn, on top of multiple sets of infrastructure, IDEs, etc.

Why You Should Switch from Subversion to Git

Related Stories