26

I searched and couldn't find any business reasons why git/mercurial/bazzr systems are better than centralized systems (subversion, perforce).

If you were trying to sell a DVCS to a non-technical person what arguments would you provide for the DVCS increasing profit.

I will shortly be pitching git to my manager, it will take some time converting out subversion repositories and some expense in buying smartgit licences.

Edit I tried to make this question into a generic discussion on centralized vs decentralized, but inevitably it has turned into git vs subversion. Surely there are better centralized systems than subversion.

Improve this question
4
  • 1
    We're in a similar position looking at making the case and it has to be said, I'm not convinced that there is one at present.
    – Jon Hopkins
    Jan 7, 2011 at 11:45
  • Could git-svn meet your needs?
    – JBRWilkinson
    Jan 7, 2011 at 14:27
  • @JBRWilkinson I've just used git-svn to migrate a bunch of repositories to git. The company doesn't have much invested in tools that integrate with svn so it wasn't much of a problem.
    – Benbob
    Jan 7, 2011 at 14:43
  • Ref the edit - you still haven't explained how and why SVN is failing you such that you feel you need a replacement. My answer (for example) is NOT about git vs svn its about finding a business case for changing the status quo.
    – Murph
    Jan 8, 2011 at 13:08

11 Answers 11

Reset to default
23

Hmm, having been a manager I have two immediate "knee-jerk" reactions to this:

  • If you don't already have good reasons why are you pitching git other than to be trendy?
  • Similarly, how is Subversion failing such that you need a replacement?

I'm not, actually, being negative - I think there probably is a case to be made (dependent on circumstance) but if the case is simply that git is "better" than subversion then you don't really have one.

You also need to be able to enumerate the disadvantages - you've already identified the overhead of migration and re-tooling - what else is a problem? e.g. What happens to your nice, central, backed up repository? How do you integrate with your continuous integration build server (if you don't have one, forget git and go sort that first). Oh security and tracking - SVN runs with proper logins and permissions.

To my mind, the benefits are in flexibility, better merging, the ability to do local commits without breaking the build and so on. The disadvantages are in lack of control and that same flexibility.

It may be that all you want to do is run git locally to your machine as a "better" subversion client (I'm looking at doing this using mercurial).

Hmm, perhaps this whole answer is a comment really? You need to make your case here (in the question) for git over subversion (in your environment) in order to see if we can help you identify the business case.

FWIW, I'm know that one can easily designate a specific instance of the repository to be the trunk/reference source and further that that is how one wires into one's build server - the difference being that with DVCS that's more of an administrative decision than something inherent in the architecture.

Improve this answer
2
  • 1
    Addressing the permissions/flexibility concerns: you still need a "source" repository too, where you can actually set the rights as usual. Continuous Integration runs for the source repository, developers clone the source repository etc... Its backup is less important though, since everyone has a clone, not just a checkout.
    – Matthieu M.
    Jan 7, 2011 at 17:45
  • 1
    Point about full clones being backups is well made. I will freely admit there are some areas of this I don't understand well enough as my "work" stuff is svn and my mercurial is personal and, as yet, somewhat limited.
    – Murph
    Jan 8, 2011 at 13:06
14

I would say the quick and painless branching and merging would allow developers to be more productive with their code, as every new feature could be branched, then later merged. Making the development process go by much more smoothly. Also, the distributed nature, would allow every developer to have an entire copy of the code, so there is no worry of a centralized server failure taking down all of your code. There is probably more reasons, those two, however, are my top reasons for using Git.

Improve this answer
7
  • 2
    In a business environment, the 'centralized server' would have redundancy, backup and admins responsible for keeping it (and all other servers) alive.
    – JBRWilkinson
    Jan 7, 2011 at 14:30
  • 2
    In a large business environment, you would have server redundancy. In a small business such server redundancy is not so certain.
    – Michael Shaw
    Jan 7, 2011 at 17:05
  • 2
    A centralized server failure wouldn't take down all your code. Even if you didn't have backups, the worst it could do is take down your revision history. But as long as all the developers have the code checked out, it exists in current form on their systems too.
    – Mason Wheeler
    Jan 7, 2011 at 17:56
  • 1
    @mason: but that is quite an assumption: 'as long as all the devs...". Because on small scale companies with even smaller scale projects, projects may live and are being used happily without anyone coding on it for a year or two.
    – Inca
    Jan 8, 2011 at 10:04
  • And also, I wouldn't underestimate the value of commit history. In a huge system it can be really valueable to see who and why did something to the code.
    – Tamás Szelei
    May 21, 2011 at 16:01
8

I assume you can make a case for version control increasing productivity (and thus profit) even when a developer is working alone.

A good DVCS recognizes those same productivity benefits even when working as part of a team - each developer can get all the benefits of working with version control - they can make frequent commits, rollbacks, play around with things, etc. - without worrying about conflicts with what other developers are doing until they're ready to push their changes out.

Improve this answer
5
  • This is what I was going to post, pretty much. You should certainly see productivity improvements from developers committing early and often to their own repository, without causing any trouble for any of their co-workers.
    – Carson63000
    Jan 7, 2011 at 4:19
  • 5
    Then you'll be in integration hell when you eventually do push your changes. This is a bad thing not a good thing.
    – Henry
    Jan 7, 2011 at 4:48
  • As you are doing local development with lots of commits you can continue to pull changes from the central repository and keep your local changes in line with the ongoing development that others are working on. Thus when it comes time to push your changes to the central repository you should already have the majority of the changes that have been happening there and integration will be easy.
    – DaveJohnston
    Jan 7, 2011 at 9:58
  • 1
    Unless one of your coworkers has done the exact same thing and both of you haven't integrated for quite awhile. There is always trade off. I do have seen cases where stuff had been integrated on the mainline where they shouldn't have been (wrong solution, dead-end attempt at a solution and such), integrating at feature completeness has it's perks also.
    – Joppe
    Jan 7, 2011 at 14:10
  • 2
    Can't you do all of these things with (a) SVN branches or (b) multiple working copies?
    – JBRWilkinson
    Jan 7, 2011 at 14:29
4
  • Branch-per-bug
  • Reduced latency on your diffs.
  • Being able to very quickly navigate arbitrarily through the history of a branch when you're peer reviewing.
  • You still have access to your entire history when you don't have access to the centralised server: you're not in the office, power just went out but your laptop's battery's still working, ...

These things let you work more efficiently, both solo and in a team. More efficient working = faster development time = quicker time to market = profit.

Improve this answer
0
3

Forgive me for linking to my own blog, but I've written articles on this very subject:

Feel free to downvote if you don't find them relevant.

In a nutshell, DVCS makes branching models easy that can keep large groups of developers from stepping on each other's toes, which increases both productivity and your daily build quality. The messy collaboration part of version control can be done in local repos, leaving your central repository cleaner and of higher quality. Also, decisions about when to branch can have a big effect on efficiency, for example if one department is ready to start work on 2.0 when 1.0 is still being cleaned up by others. DVCS allows those decisions to be made on a local level instead of by committee.

Improve this answer
3
  • Your blog entries are well written. I haven't yet read all of them though. I wonder why you have chosen Bzr when Git and Hg seem to be far more popular. People seem to hate Bzr for being slow. I'm also a fan of Git because of the tree hashes instead of revision numbers, which seems very secure to me. Won't the bzr rev numbers get all scrambled up when branches are merged?
    – Benbob
    May 21, 2011 at 13:12
  • 2
    @Keyo, I chose bzr because I had to teach DVCS to myself and bzr is the most newbie-friendly. I have switched to git for speed, features, and stability since then. Bazaar also hashes its revisions and has globally unique identifiers, they just aren't the default exposed to the user. Their revision numbers are really no different than using HEAD~1, HEAD~2, etc. in git. It's very rare you need the actual hash, but it's the first thing you learn in git and is always in your face. Hiding that from the user unless you really need it is one reason bzr is more newbie friendly.
    – Karl Bielefeldt
    May 21, 2011 at 14:19
  • Thanks for the clarification. Git wasn't exactly easy for me coming from subversion. A lot of the commands have the same word but do different things.
    – Benbob
    May 22, 2011 at 2:50
2

My arguments for DVCS are these:

  • Branching isn't broken, which leads to less friction in developing features and keeping existing products patched. Friction costs money in time.

  • Moving to a modern system better attracts cutting-edge developers, which will lead to a culture of better products, which enables the business to sell more products.

  • Non-network commits are faster, allowing the developers to commit often, leading to fine-grained bug detection and analysis.

Essentially, it's about reducing friction. There is a term for this: Muda. The more friction, the more of a pain it is to do things. The more pain, the less gets done, the fewer profits.

Improve this answer
2

I apologize if I'm grandstanding, but allow me to put the business case in no uncertain terms:

SVN makes developers' lives miserable. And that makes a software business miserable.

...in ways that many won't realize until they start using a DVCS. This is the most important business case that can possibly be made. Why? Well, compared to the cost of finding and retaining good developers, the cost of switching to a DVCS is almost non-existant.

Consider the following:

  • All but the most trivial operations in SVN (and most other CVCSes) require network access. In most DVCSes, network access only occurs when you do a push or pull operation. This means that non-trivial commands are slow. What do you do when a command is taking forever? I personally go browse programmers.se or hacker news while I'm waiting. Simply put, DVCSes allow programmers to focus on doing what they love: writing the company's software.
  • SVN has support for branching in much the same way prisons have support for dropping your soap in the shower: you can do it, but when you do you get fucked. Thus, SVN forces your developers to constantly fight over each other to make changes.
  • When SVN is down, it's down. It becomes terribly difficult for developers to do their jobs if they can do them at all. Thus, SVN forces your developers to be reliant on your infrastructure being 100% bug-free.
  • These days, git is rapidly gaining mindshare while SVN is rapidly losing it. If there are no benefits to using DVCSes over SVN, why is the programming community changing as fast as they can?

What does all of this amount to? I have yet to meet a developer that's given a DVCS an honest try that would prefer SVN afterwards. If I could make one more annoying, bolded statement, SVN is a "necessary evil" that developers force themselves to use. Git is a tool that makes developers more productive and happier.

(I should point out that the bolded statements are the particular ones you should focus in on. The rest of them just provide context.)

Improve this answer
7
  • 5
    -1 - you are grandstanding and whilst there is some truth in what you write it is spun so negatively as to verge on FUD rather than reasoned analysis. Is SVN slow? Only if the repository is vast and the network glacial. Does SVN being down stop me working - erm, can't remember it ever being down and NO since my computer does not depend on the existince of the repository to edit/compile/run the source. Is SVN branching and merging poor? Wow people have short memories... why is DVCS gaining mindshare? A mishmash of functionality - which is improved - and, frankly, fashion.
    – Murph
    Jan 8, 2011 at 13:13
  • 1
    @Murph - Like it or not, people hate change to the point of being torpid. To convince them to change, you need to convince them that the status quo is broken. And it is broken. FUD is only bad when there is no reason to be fearful, uncertain, and doubtful. As for mindshare, I agree with you. But that's not really the point. It's whether or not the people who make decisions agree with it. And every manager I've ever met has been convinced by this argument (even if they hate git).
    – Jason Baker
    Jan 8, 2011 at 14:46
  • 2
    I'm not necessarily disagreeing with you Jason merely suggesting that your points are not well made. Specifically I think you're exagerating for effect and if you get caught doing that you tend to lose points for your argument even if you're right. (Except for the points where you're wrong of course... (-: )
    – Murph
    Jan 8, 2011 at 17:42
  • 2
    All of your points are matters of opinion rather than facts. I'd enumerate each but there isn't enough space in comments. How about you answer again without the grandstanding?
    – Henry
    Jan 8, 2011 at 23:17
  • 1
    @Henry - Programmers.se is for subjective questions and answers. Subjective == matter of opinion.
    – Jason Baker
    Jan 9, 2011 at 3:44
1

The only thing I can think of is that git works without a network connection. Everything else is even often hard to sell to technical users who use subersion or perforce for quite some time.

Improve this answer
2
  • 2
    Sure, but Subversion mostly works without a network connection too. (Not committing obviously, but common things like getting info about the working copy or diffing with the base revision all work.)
    – j_random_hacker
    Jan 7, 2011 at 5:42
  • @j_random_hacker: The point of a VCS is to track code changes. Committing tracks code changes. If you can't commit offline, I would argue that that your VCS does not work while offline.
    – Daenyth
    May 21, 2011 at 19:00
1

The difference show when there is trouble

We switched to git 6 months ago after porting our decade old repository.

So far I've found the following, after a bit of experimenting:

  • branching and merging is almost painless. This makes it much easier to work on separate features and bugfixing without stepping on each others toes. It also makes it very easy to apply a given bugfix somewhere else too.

  • more robust by design - you do not rely 100% on a central server being available, and if it isn't you can use promote any clone temporarily as a hot replacement. This removes a crucial point of failure - if the SVN server goes down for any reason, nobody can do SVN work. If the central git repository goes down for any reason, you can still work and push/pull locally to ensure that the commits are replicated. You can even have multiple off-site repositories for exactly this purpose.

  • repository interaction is simplified. For CVS you essentially needed access all the time anytime you needed some piece of information. For git the whole repository is locally available allowing many things to go faster.

So, the benefit is not as much in the daily routine, but is very clear the moment you have something not working correctly!

Hence, I suggest that for your business case, look at what you will do when disaster strikes...

Improve this answer
1
  • It is the same argument as for backups: You only need them when disaster strikes. Question is what you will do when it does, and what you will accept happening then.
    – user1249
    May 21, 2011 at 14:04
0

The ease of branching and merging is the most concrete reason, but to convince someone you'll have to give them a concrete example of how that improves things.

Let's say you have a few programmers working on performance improvements for an app, and they are in the experimental stage and don't know if the code they are writing will ever be part of the master/trunk branch. However, they need to frequently share code with one another and try out ideas that may be dead ends. How do you manage such frequent branching and merging in subversion? The short answer is that you don't. With a dvcs it's really easy, and the programmers can quickly try out new ideas in branches and share with others before deciding if that idea will stick around.

Improve this answer
-1

The business case for ditching SubVersion is the branching support is a barrier to product stabilisation and maintenance. If you need to release a product and then continue development you need a branch. With subversion, the developers will not use branching properly, and so you will fail to keep development on the tunk, and ensure that bug fixes actually make it onto both the trunk and the branch as well.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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