Centralized vs Distributed Version Control Systems [CVCS vs DVCS]

We read the concept/benefits/types of Version Control Systems in our last article.

Now, I am going to shed some light on the differences between Centralized Version Control systems and Distributed Version Control Systems.

If you are fairly new to SCM and version control systems, you can direct your browser to this article where we have covered some very commonly used terms in VCS.

So, here you go…

The concept of a centralized system is that it works on a Client-Server relationship. The repository is located at one place and provides access to many clients.

Central Version Control SystemsWhereas, in a Distributed System, every user has a local copy of the repository in addition to the central repo on the server side.

Distributed Version Control SystemsCentralized Version Control is the simplest system with the concept of 1 central repository which servers provides latest code to the all the clients across the globe

Distributed Version Control provides flexibility and has emerged with the concept that everyone has their own repository, they don’t just check out the snapshot of the code – they fully mirror the central repository.

CVCS is easy to understand whereas DVCS has some complex process for beginners.

CVCS is dependent on the access to the server whereas DVCS provides the benefits to work offline. Everything except push and pull the code can be done without an internet connection.

CVCS is easy to administrate and has more control over users and access as it is server from one place.

DVCS is comparatively fast comparing to CVCS as you don’t have to contact the central server for every command. DVCS just takes much time on the first check-out as its mirroring the central repository on your local.

If your project has a very long history and change-sets then downloading the entire history can take an unreasonable amount of time and disk space in DVCS whereas CVCS allows you to checkout only few lines of code if you just need to work on few modules.

DVCS provides a powerful and detailed change tracking, which means fewer conflicts at the time of merge.

DVCS gives an ability that developers can share changes with one or two other members of team at a time if they want to get some feedback before showing the changes to everyone.

The revisions in DVCS are typical big guids (like fa333b7rer96cd6d3b0037d660) – it’s not incremental numbers (which is provided by CVCS) which make them harder to reference and remember.

DVCS provides an advantage wherein if the main server’s repository crashes, you still have a local repository in every developer’s local space from which you can create the main repository.

SVN and CVS are the popular tools of CVCS

GIT and Mercurial are the popular tools of DVCS

I hope now you have a good idea of differences between the different version control systems – Centralized and Distributed.

27 thoughts on “Centralized vs Distributed Version Control Systems [CVCS vs DVCS]”

  1. Appreciating the time and effort you put into ypur website and in depth information you present. It’s nice to come across a blog every once in a while that isn’t the same outdated rehashed information. Excellent read!

  2. Pretty element of content. I simply stumbled upon your weblog and in accession capital to claim that I acquire in fact enjoyed account your blog posts.

  3. Thank you for another magnificent post. Where else may anyone get that type of nfo in such an ideal means of writing?

  4. i appreciate article, but i want raise some question hare.can do work multiple developer on one project like
    Q.1-if Projects A and working developer on this 10 and 2 to 4 developer working on same page but not updating push and pull command in GIT then how to all developer get continuous latest code of this page.
    Q.2- can we work together on SVN and GIT

    1. Hi Devendra,
      Sorry for delay in reply – I just missed this comment
      Yes if you really want, you can use git & svn together (please refer https://git-scm.com/docs/git-svn) which provides a bidirectional flow of changes between a Subversion and a Git repository., however it would be recommended to use one VCS as per your project/developers/system/organisation requirements.
      You can then use ‘git svn fetch’ to get all unfetched revisions from the Subversion remote we are tracking.

  5. I’m more than happy to discover this web site. I want to to
    thank you for your time for this particularly fantastic read!!

    I definitely savored every part of it and i also have you bookmarked
    to check out new information in your site.

  6. I needs to spend some time learning more or understanding more.
    Thanks for great information.

  7. Way cool! Some very valid points! I appreciate you writing this write-up plus the
    rest of the website is also very good.

  8. Thanks for your interesting article. I am a teacher from Germany writing a script for my students about that topics and like to insert your illustrations. Is it possible to get a scalable version (PDF or SVG) or the graphics?

  9. I am transitioning from CVCS (SVN, QNX Rational Team) to DVCS (Git) and some of the concepts are confusing to me.

    1) CVCS – The repository is located at one place and provides access to many clients; DVCS – every user has a local copy of the repository in addition to the central repo on the server side
    >>> I have used SVN, Clearcase, QNX RTC and there is local copy of code in these systems as well. This local copy has same folder structure as on server/central repo.
    Could you please explain this in more detail?

    2) CVCS is dependent on the access to the server whereas DVCS provides the benefits to work offline.Everything except push and pull the code can be done without an internet connection.
    >>> I have used SVN and that did not need access to internet unless I have to check-in code to repo to overwrite my changes with “update” operation. I could make changes locally and test.

    3) Is the commit/check-in operation a multi stage process in DVCS that makes it different? say developer commits his/her code changes in Git. Then their computer crashes. Will they be able to recover the change since commit actually does not deliver changes to central repo?

    1. Please find below my explanation for your queries :
      1) In git, the local repositories are exactly the replicas of the central repository with the entire history of changes so if central repo is crashed you can restore from your local whereas same cannot be done in svn
      2) With svn, you can add/delete/edit local files, but if you want to register any changes into the repository, then you need the network access, whereas In git, you can make changes offline. The network is only required for the sync up process between your local git repository and remote repository.
      3) The simple answer is NO, since it was just a local commit and your changes are only available in your system. However you can setup and post-commit hook to push your changes to remote as soon you commit in your local. You can use disk utilities to recover your data.

      Please remember both tools and processes are great in their own extent and have pros and cons, its shear project’s choice which one to pick 🙂

      1. From functionality point of view only difference between CVCS and DVCS is that in case server crashes, we can recover easily in case of DVCS.

        Other than this I dont find ant major difference.
        In both the cases developer has to copy/clone from server, do the changes and push back the changes to central server for team to view it

  10. Hi there, You’ve done a fantastic job. I will definitely digg it and personally recommend to my friends.
    I am sure they will be benefited from this site.

  11. Do you mind if I quote a couple of your posts as long as I provide credit and sources back to your
    site? My blog is in the exact same niche as yours and my
    visitors would really benefit from some of the information you provide
    here. Please let me know if this alright with you.

    1. Hi Kam,
      That would be fine as long as you provide proper credit and acknowledgement.
      Basically this information is helpful to all of us, more you share more you spread the knowledge…keep questing

  12. I am really happy to glance at this webpage posts
    which consists of lots of helpful information, thanks for providing such information.

Comments are closed.

Scroll to Top
Scroll to Top