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.

Benbob
  • 1,206

11 Answers11

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.

Murph
  • 7,843
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.

mbreedlove
  • 648
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.

Anon.
  • 2,195
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.

Frank Shearar
  • 16,751
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.

Karl Bielefeldt
  • 148,830
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.

Paul Nathan
  • 8,560
  • 1
  • 34
  • 41
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.)

Jason Baker
  • 9,653
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.

Brainlag
  • 165
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...

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.

jshen
  • 101
-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.

Michael Shaw
  • 10,114