9

It's been only several years since I migrated from Visual Source Safe to SVN. And SVN for me is still kinda "WOW! I can do so many things! SVN is so cool!"

But many people around me keep saying "SVN? Really? Meh..."

And there's so many of them that I'm worried. Should I move my team to Git / Mercurial or some other fancy thing? I know I sound ridiculous and the obvious answer would be "stay with what works for YOU". SVN does work for me... But every time I create a new project in my repository I keep asking myself - may be this was the time to move?

So... Is SVN really that bad? Do I miss a huge opportunity by sticking with it?

7
  • This might be an interesting read : stackoverflow.com/questions/161541/svn-vs-git
    – fouronnes
    Mar 15, 2011 at 21:02
  • Are you a standalone developer? Mar 15, 2011 at 21:03
  • 6
    I always used GIT. Now I have to use SVN at work.... ... ... ... ... ... ... RAGE.
    – Ivo Wetzel
    Mar 15, 2011 at 21:04
  • @TeaDrinkingGeek: OP says "Should I move my team..." so I'm guessing there's more than just the OP involved (unless you count a team of one a team - but then it's not usually referred to as "my team"). Mar 15, 2011 at 21:04
  • lol sorry mate, eyes are a bit blurred after 12 hrs on the laptop. :) Mar 15, 2011 at 21:10

5 Answers 5

8

It entirely depends on usage.

If you have one team of people in a room and they do most of their work there, if you have a build and deploy process you already like, and if you are not looking to share your code with people widely (as you would with an open source project), then you shouldn't sweat it.

I switched maybe a year ago from Subversion to git. Git perfectly adequate for that mostly-local use case as well, but where it really shines is distributed development. Used locally, it's nice to have github as a remote backup and pretty web interface to the code, and it makes it easy for me to let contractors participate. But I'm not getting much out of it right now that I wasn't getting from Subversion.

8

Don't get swept away in the constant stream of hypes. You have something that works, keep using it until there's a business requirement that is better met with something else (no, a shiny new source control system or programming language every few months, whenever something "new and improved" is hyped, is NOT going to meet your business requirements any better than the one you're using now).

If SVN works for your organisation, there's therefore no reason to invest the money/time/effort needed to move to something else, however much some people want to because it's new and shiny.

And no, that's not (as JBK thinks) a decision that should be up to "the team", it's a decision that's up to management after consulting with all interested parties (which includes your sysadmins at least). It's a business decision to spend money on changing your technology stack, not a technical decision.

1
  • I'd upvote you a million times if I could.
    – HLGEM
    Jun 7, 2012 at 22:42
5

I believe one should never make decisions out of ignorance. If you don't know what you're missing, you should try git out long enough until you do, then you can make an informed decision. The jump to distributed control can't really be comprehended without trying it out, and letting go of some old habits while you do. Most of the power of DVCS is that you can create as many branches as you want, for whatever reason you want. If you try it out for a month and haven't created at least 5 branches or so, you didn't test it on its own terms. This is the mistake of most people who don't "get" git. After that, if you go back to svn, at least you will know the reasons for yourself.

2
  • 5
    I'm strongly in favor of making most decisions out of relative ignorance. You suggest he take a month to try out git. That's real work. He should only do that if there's some reason to believe it will make his situation a lot better. Otherwise, there's probably something else he should spend his month of experimentation on. E.g. redis or mongo or rails or node.js or BDD any of the equally hot new things. Mar 15, 2011 at 23:00
  • But Git is a hot new thing. And the experience of many Git users suggests it will make his situation a lot better.
    – Kyralessa
    Aug 2, 2011 at 19:29
3

I haven't used Git, but I've used Mercurial, and I really don't see what the big deal is. It feels a whole lot like SVN, except that basic stuff like checkin and checkout are more complicated (requires two steps instead of one). In return, it's supposed to make a lot of more advanced stuff that I've never actually needed to do a lot simpler. My reaction to claims of DVCS being somehow inherently superior is basically, "OK, sure, I'll take your word for it," and then I continue on with SVN, which works just fine for me.

5
  • The huge deal about DVCS is that you can do all of your work "offline." That one feature imposes the requirement that the DVCS have a powerful merging mechanism that can handle rebasing and branching; the kind of tasks that are simply not possible with a centralized VCS. The superiority people claim comes from the enabled workflows rather than technical superiority. If you don't use or need that kind of workflow, that's okay too.
    – greyfade
    Mar 15, 2011 at 23:49
  • 1
    Thats because checkin and checkout don't exist in DVCS. You are using hg as a replacement for SVN rather than using hg the way its meant to be used. The same would apply for any DVCS. Mar 16, 2011 at 0:33
  • @Mathepic: Well, you can change the name if you want to, but the fundamental concept of transferring data between the local working copy and the official repository exists in any source control system. Mar 16, 2011 at 1:46
  • 1
    no it does not. There is no such operation in a DVCS. Mar 16, 2011 at 19:56
  • 3
    yes there is - the point of a central repo to push the 'master' version to is a very valid use-case, either for backup, build-server, release management, or just a way to co-ordinate better between teams.
    – gbjbaanb
    Nov 9, 2011 at 23:50
-2

The obvious answer here is to let the team decide and have a discussion about what is the best option for everyone so that it isn't someone calling the shots in a vacuum. There may be various opinions and concerns to be addressed but I'd rather suggest going for a consensus answer rather than trying to be dictatorial about what to use.

1
  • 3
    Do you have any idea of the cost in manhours of changing from one source control system to another or the risk of losing things in the process if someone new to the new system makes a mistake in converting existing code? This is NOT a team decision, this is a business decision and should only be undertaken if you have real needs that your current system can't meet.
    – HLGEM
    Jun 7, 2012 at 22:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.