Does the choice of using a DVCS over a CVCS actually make for shorter release cycles? If so, what makes software release cycles shorter and what are the arguments for this?

  1. Related to pull request? Does easier submission of patches play a role here?
  2. Related to people factor? Are project teams that use CVCS act more conservative with release schedules?
  3. Any other factors?
  • I edited out some of the more presumptive "facts" and loaded questions that some might find insulting and reopened the question. It should be altogether a more unbiased and focused question than before but if you disagree then let me know.
    – maple_shaft
    Commented Jan 21, 2013 at 14:10
  • If the DVCS makes the team more productive, then YES. If the DVCS does not make the team more productive, then NO. There's no magic in DVCS, it's just another tool.
    – MrFox
    Commented Jan 21, 2013 at 16:10

4 Answers 4


What makes software release cycle shorter with DVCS, compared to CVCS?

I don't think there is necessarily a difference between DVCS and CVCS here, but rather a difference in the branching model that people adhere to.

From what I have gathered here and from my experience, people using DVCS tend to use more branches than people using CVCS. And if you develop each feature in a branch of its own, it is easier to start preparing a release with new feature X in it, but not feature Y, whose development has started but which is not yet ready for a release.

  • Well, the branching model people adhere to is very much affected by what their version control system makes easy. And there is a difference in this.
    – Jan Hudec
    Commented Jan 18, 2013 at 9:55
  • 3
    The fact that branching (and more importantly merging) is easier in DVCS than in most CVCS is however not a property of being distributed or centralized. It would be perfectly possible to have merging be as easy in CVCS as in DVCS. It's just that the typical users of CVCS have never experienced an easy merge, therefore they don't know that it is even possible, and thus they don't ask the vendors for that feature. DVCS OTOH would be useless without easy merging. It's the Blub Paradox, basically. Commented Jan 18, 2013 at 13:33
  • The branching model becomes really hard when it is conceptually difficult to separate features into branches and there is a lot of cross-bleed. This is not a problem of CVS implementation. When this happens you need one trunk and frequent commits not 'better merging'. Some things really do need to be centralized.
    – MrFox
    Commented Jan 21, 2013 at 16:21

Everyone here seems to agree that projects using DVCS have shorter release cycles over all, but it's still not certain that the adoption of a DVCS causes the shorter cycles: Correlation is not causation!

Distributed VCS and short release cycles are both relatively new technologies. Projects that embrace one are likely to embrace the other, while groups that prefer the tried and true, or that have a long-established workflow, will be more conservative and stick with CVCS and less frequent releases.

A better question to ask would be: "In what ways does use of a DVCS facilitate the short release cycle model?" This is what most of the answers are addressing, as a matter of fact. Using a DVCS doesn't prevent anyone from having long release cycles; adopting short ones is a choice, and it involves development methodologies, branching models, code reviews, etc.-- not just the VCS.

  • 1
    +1 for first paragraph. DVCS is standards amongst new exciting nimble startups, but has little inroads in big waterfall-style enterprise projects. The level of complexity, the environment, and the product types are really not the same.
    – MrFox
    Commented Jan 21, 2013 at 16:14
  • @suslik There are quite a few enterpries using BetKeeper or Sun TeamWare for quite some time already.
    – johannes
    Commented Jan 21, 2013 at 17:01

Good question!

The CVCS believe in the primary principle that everything must keep merging/syncing back to 'the trunk'. Also, we expect that as we evolve, trunk should be the most stable points before release is made. So people put their work in working copy, take update and test before check-in. Or alternatively, you work on private/feature branches and then merge other trunk changes, test before you reintegrate.

The DVCS pattern can be significantly different. You keep branching and forking yourself. You may experiment, and then finally merge branches which make sense. Occasionally you heard of some security fix that must go out immediately, so you want that patch to be in your branch as well, but you don't want many other stuff of trunk! So by default, you keep working in your space, keep taking and integrating things - and the time comes for release you all sit an decide what to take what to drop.

See this: http://nvie.com/posts/a-successful-git-branching-model/

So the essential difference is this: CVCS asks what mother says to their of young children -don't go far away beyond a point where I can find you i.e. - keep synchronizing to trunk. The DVCS works assuming that all work is design to be independent unless there is explicit need to merge (e.g. creating a release).

Now coming to your question -

The above explanation actually sounds more contrary to what you observed/asked. The real challenge is, defining what is stable! when the number of user base is very large, and while people keep pouring their deltas - each of them might have counter breaking with respect to other parallel changes till everyone is settled to their individual best as well as the entire integration and dependencies are ok. So when you are trying to make release, one need to really shake things up, stop people from pouring new features - identify any integration issues when things merge up and so on. All this, implies that CVCS always ask you to take 'release breaks' between the development!

When number of contributors become large, getting to this point of 'release breaks' becomes difficult and fewer; and hence CVCS will actually force you to make 'release creation festivals' after a very significant one.

In DVCS - you keep working, testing, working testing on your own space. The release creation and integration is quite a parallel activity and it can also afford to do try and error by seeing what patch-sets work together and what won't (hence will be taken or dropped from releases). In DVCS - you can decouple individual development and then once in a while just sneak in a release if that make sense.

  • What are 'release breaks'?
    – linquize
    Commented Jan 18, 2013 at 7:25
  • A small pause in development till trunk is stabilized to create a release! This may or may not be significant depending on the maturity of the developers. Commented Jan 18, 2013 at 7:28
  • 2
    I don't buy the 'release breaks' argument. It seems to me that that is a problem with your branching rather than CVCS as a concept.
    – James
    Commented Jan 18, 2013 at 14:39
  • +1 @James. My group was used to "release breaks", or "code freezes", when we used a seriously out-of-date version of PVCS. We've moved to TFS (most definitely not a DVCS) and use branches, not "breaks", to stabilise releases. It's hard to break the devs of thinking about a "code freeze" for each release, though.
    – DaveE
    Commented Jan 18, 2013 at 17:23

What makes software release cycle shorter with DVCS, compared to CVCS?

I agree with Bart that the primary reason is the branching model used, but the type of version control system directly affects which branching models are viable. So we have two sub-questions. What branching model the distributed systems support better and why it makes release cycle faster?

The fundamental difference between centralized and distributed version control is, that without central authority you can't enforce linear timeline. So to make distributed version control possible, these systems necessarily had to define history as directed acyclic graph, where each revision simply has unique identifier, one or more parent revisions and may have arbitrary many child revisions that you might not even be aware of, because you didn't synchronize with the system where they were created yet.

It turns out that this approach lends itself very well to branching. You don't have to do anything to get a branch, you simply always have one. So you can dive straight to work head first and leave deciding when and where to merge it or even where to keep it and under which name until you know whether it's actually going the way you need.

In contrast all centralized systems maintain history as set of branches with linear sequence of revisions. So you have to decide in advance whether you'll need a branch, give it a name and explicitly created it. This is quite pain in the butt when you don't yet know what the idea is worth and you often simply don't know that before you start programming. Complicated by the fact that in most centralized systems the branch names are global, significant, often persistent and not easily changed, while in all the major distributed systems they are just local monikers that can be changed at whim and recycled freely. And by the fact, that all the branching and merging operations are usually quite a bit slower in CVCS.

Thus DVCS makes branches easier and therefore teams using DVCS branches all the time while teams using CVCS will be avoiding them most of the time.

Now why using branches allows more frequent releases? Well, every team will underestimate a task now and then, often when hard to track bug appears. Teams using centralized systems usually do all debugging, and most development, on trunk, because branches are inconvenient. So they can't release until they flushed out most bugs and they have to interleave development and debugging phases.

In contrast in distributed systems where all work is done on branches these can be merged together for test, tested, bugs fixed and only the work that passes tests merged separately to trunk. Resulting in trunk that has very few bugs and thus can be released more often, usually whenever an important feature lands.

It also helps that whenever there is a change in priorities, the work in progress can be trivially shelved with the branching approach used with distributed systems. In most real projects, changes in priorities happen all the time.

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.