Home > Version Control > The “D” in DVCS stands for “Different People”

The “D” in DVCS stands for “Different People”

Someone on Stack Overflow disagreed with me about using centralized version control for a solo project. As I predicted, of course; as I said in my last post, DVCS is a fad and it will have many converts who support it in a knee-jerk fashion. I think the person who disagreed may just be misinformed, or not thinking about this hard enough. I may not have made things clear in my last post, however, about why centralized version control makes more sense for a solo developer. Also, I admit that it’s paradoxical that someone would use centralized version control for a solo project. However, as I’ll show, centralized version control does make more sense (not only that, but I’m not the only one who thinks so).

Consider this: if you are a solo developer working on the same machine all the time (e.g. a laptop), a DVCS repository in your current working directory and a Subversion repository in your home directory are practically the same. The repository is always online and you can always make commits. This is what makes the “commit while offline” argument of DVCS proponents so weak: for certain situations you can do that with Subversion, or most of the time you won’t need to.

Now consider that if you are a solo developer working on multiple machines, DVCS only creates an extra step in your development. I always work on my big ol’ workstation during the day. If I were using git or hg for my most-frequently-worked-on projects, I would need to remember to push my changes from one repository to the other. With Subversion I just don’t have that step. All other steps are identical with the two workflows.

All through those above arguments, I am only one developer, and this is the crux of the idea. I think people often confuse the situation of multiple computers with that of multiple people. In the former argument, I posed that with one computer there is no difference between using file URLs and using a DVCS repository in the current working directory. However, there would be a difference if there were multiple developers. Then you have to configure access to a single machine (either for cloning or checking out) for multiple users; this is when things get more complex.

The “D” in DVCS stands for “Different People.” What I mean by that is that the “forking is fundamental” argument posed by DVCS proponents doesn’t apply when there’s a single developer or author working on a project. If by myself I want to create branches and work on different features, that is perfectly easy to do with Subversion, and so is merging. What distributed version control is for different people maintaining different features and seeing how they work. I completely reject the idea that centralized version control is obsolete and I will keep recommending it to solo developers.

  1. Jakub Narebski
    September 7, 2010 at 04:37

    First, it is easier to put some directory under version control in (most) DVCS than in CVCS.

    Second, centralized VCS with repository on workstation is good if you can be ensured to always have connectivity: think laptop.

    Third, in the case you would want to move your formerly private repository to some software hosting site, I think it is harder with centralized repository than with DVCS, where you can create repo and just push to it.


    • September 7, 2010 at 08:45

      Hi, thanks for reading.

      As for your first point:

      # svnadmin create ~/.svn_repo
      # svn import myproject file:///home/joel/.svn_repo

      How hard is that? You do need to check out the code for the current working directory to become a working copy. That is something Subversion could do better (and maybe it will soon).

      My point about network connectivity was that DVCS proponents need to come up with a better first argument to support the adoption of DVCS; yes, I’m not firmly on the DVCS side, but I think that’s so simplistic it’s a disservice to their cause. I think it relies on convincing people who don’t entirely know what version control is. They should be promoting DVCS based on the ease of creating a repository as you did! See my previous post.

      Your third point gets at something that, in particular, Bazaar promotes itself with, and I think you’re right, if you’re going to use the push feature. However, I’ve imported two SVN trees to hosting sites (launchpad and Savannah) and I had absolutely no problems.

      How does my general argument hold up? Unless I have multiple personalities, I have a hard time seeing a distinct advantage to using DVCS on a solo project.


      • Jakub Narebski
        September 7, 2010 at 11:43

        Having only to do “git init” to put project under version control is IMVHO certainly the advantage of Git (and other DVCS).

        It’s nice to hear that software hosting sites supporting Subversion allow for easy import of history also in the case of centralized SCM.

        I think that my second point stands, at least in some situations, i.e. where you have workspace and laptop, and you don’t always have full connectivity between them (taking laptop when travelling).


  2. September 7, 2010 at 11:51

    Jakub Narebski :

    It’s nice to hear that software hosting sites supporting Subversion allow for easy import of history also in the case of centralized SCM.

    Yes, and I’ve completely forgotten to mention that a reason people should learn to use the various DVCS tools is that a lot of people are using them. One of my projects is now in Bazaar at Launchpad, imported from my Subversion repository.


  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: