Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question
    
This might be an interesting read : stackoverflow.com/questions/161541/svn-vs-git –  otibom Mar 15 '11 at 21:02
    
Are you a standalone developer? –  TeaDrinkingGeek Mar 15 '11 at 21:03
6  
I always used GIT. Now I have to use SVN at work.... ... ... ... ... ... ... RAGE. –  Ivo Wetzel Mar 15 '11 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"). –  FrustratedWithFormsDesigner Mar 15 '11 at 21:04
    
lol sorry mate, eyes are a bit blurred after 12 hrs on the laptop. :) –  TeaDrinkingGeek Mar 15 '11 at 21:10
show 2 more comments

closed as not constructive by Mark Trapp, Walter, ChrisF Mar 16 '11 at 12:06

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

5 Answers

up vote 8 down vote accepted

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.

share|improve this answer
add comment

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.

share|improve this answer
    
I'd upvote you a million times if I could. –  HLGEM Jun 7 '12 at 22:42
add comment

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.

share|improve this answer
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. –  William Pietri Mar 15 '11 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 '11 at 19:29
add comment

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.

share|improve this answer
    
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 '11 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. –  alternative Mar 16 '11 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. –  Mason Wheeler Mar 16 '11 at 1:46
1  
no it does not. There is no such operation in a DVCS. –  alternative Mar 16 '11 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 '11 at 23:50
add comment

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.

share|improve this answer
2  
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 '12 at 22:41
add comment

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