With centralized source control like Perforce and SVN, when they create a branch, they create a whole new directory. However, git and other distributed source control solutions, in my experience, are able to update the branch in place as it were. That is, they apply the differences between the two branches to the files.

This seems to me to be the far superior option as it saves huge amount of duplication for large projects, quicker to switch branches etc...

What is the reason for this? I can't see any reason why there being a centralized authority affects the clients ability to diff the two branches and modify the changes.

  • 2
    Could someone explain the downvote so I can improve any future questions on Programmers.SE
    – T. Kiley
    Aug 13, 2014 at 12:14
  • 2
    I don't believe this is a discussion; I am asking a question with a definitive answer, why don't centralized source control solutions implement a merge based branch rather than a copy? If that's not clear, I can edit it, but I already have one answer that addresses precisely that.
    – T. Kiley
    Aug 13, 2014 at 12:18
  • 2
    @T.Kiley Ask the people who build them?
    – Jan Doggen
    Aug 13, 2014 at 12:29
  • 2
    Are you asking why the subversion system was designed to model branches as zero-cost copies, and expose those as locations within the repo, or whether you can switch a working copy from one branch to another? Because subversion does not duplicate information when making a branch: it merely creates a new location pointing at the same data. Aug 13, 2014 at 20:09
  • 2
    SVN does not "create a whole new directory." It may visually, but nothing is copied: that thing is really a node on a tree, referencing a revision in the repository. It is lightweight, storing only reference data. Change that branch, and it only stores a diff of the affected files.
    – user22815
    Aug 13, 2014 at 20:58

3 Answers 3


When centralized systems create a branch, they do various things. Perforce and Subversion are unique in using directories for branches, the later copying the idea from the former. CVS has branches as separate concept from directories and so do most other centralized version control systems.

The use of directories for branches in Subversion is a neat-looking reduction to more elementary concept that unfortunately has it's downsides, because merging only makes sense for branches, but has to be implemented for arbitrary directories in this model and is generally complicated a lot by this.

Using subdirectories for branches is unsuitable for distributed systems, because branches are the basis for distribution and therefore need to be a separate first class concept.

The real difference between branching in centralized and distributed systems is that in centralized systems to create a branch you have to ask the central server, which means naming the branch in a way to avoid conflicts and round-trips to server and such while in distributed system each checkout is a branch by design, so you always already have it when you need it.

And note that even in centralized system the checkout containing local changes is kind of a branch too (with exception of ClearCase dynamic views). Just it is a branch with very limited functionality that can only contain the uncommitted changes.

Some additional notes:

Subversion can switch a branch in a particular checkout.

Subversion creates new directory for a branch, but it does not duplicate the content of the files, so there is really not much difference in storage efficiency.

A distributed system (where revision identity is maintained when moving between repositories) can't use directories for branches, but there is a decentralized system, SVK, that is built on top of subversion and does use directories for branches and works by mirroring subversion repositories.


It's a snowball effect.

SVN has been around a long, long time, and duplicating a directory was the easy-to-code solution. It was good enough because branching was rare. But then DVCS were invented partly to overcome perceived weaknesses in SVN, and they had great, efficient branching support. That lead to people using much more branching than ever, which made it even more important that branching be cheap, so now it's unthinkable ever to go back to the easy-to-code solution.

So the reason is historical accident rather than the development model - it's more or less a coincidence that Linus introduced improved branching and distributed storage at the same time (via git). Certainly you could program efficient branching storage into any VCS if you wanted to.

  • 3
    Do you have any sources that back this up? Especially the "git as a replacement for SVN" seems highly dubious to me.
    – musiKk
    Aug 13, 2014 at 12:25
  • 1
    Git was manifestly not a replacement for SVN for Linus - it was a replacement for the proprietary BitKeeper. But it took the place of "the VCS of choice for new software projects in general" from SVN, which had taken it from CVS. I'll edit that. Aug 13, 2014 at 12:27
  • 4
    The big item here is that SVN doesn't have branches (or tags). It just has files and directories. This makes for a much simpler model. Note that in the repository branches and tags don't take up much space, since they are copy-on-write. It's only when you check out multiple branches at once that they will take up additional space, but that's no different from Git either. Aug 13, 2014 at 14:16
  • 2
    -1. I disagree with about every other word of this. Subversion definitely isn't around that long. First release was 2000, which is the same year as BitKeeper and 7 years after early distributed experiment called Aegis. Distributed systems were invented to support the process people were already doing with tarballs and patches and had nothing to do with Subversion. And the only new feature Linus introduced with git was speed. He already used imrproved branching and distributed storage in BitKeeper and the git model follows monotone, only it is (or was by that time) slow there.
    – Jan Hudec
    Aug 14, 2014 at 12:00

Legacy software isn't designed, it evolves. Svn was designed to improve CVS, which was designed to improve RCS. What did RCS replace? Think about how you would maintain branches without any version control system at all. You put them into separate directories.

Putting those separate directories under version control requires a smaller leap in your mental model than git's system, which seems like an obvious improvement over svn, but is far from obvious when compared to no VCS at all.

Also keep in mind that branch switches are much faster on distributed version control systems because they don't have to go to the network. At work where you probably have a gigabit connection to your server, that's not such a big deal. When CVS was invented, 9600 baud was considered a high speed connection. Disks and CPUs were also much slower then. A git checkout of a project the size of the Linux kernel might have taken several minutes on computers of that era.

That being said, a lot of your criteria for calling git's model "superior" aren't necessarily accurate. My development computer at work has a terabyte disk drive on it. I have four branches checked out of a 60,000 file project, and am still only using 80 GB, and that includes my OS and everything else. Clearly, duplication isn't a problem. As far as switching branches, git is fast, but a cd is still faster.

Over time software tends to borrow the best features from competitors, and I think in-place checkouts will eventually be an option on most centralized version control systems. There's nothing inherently preventing it today, just history. In fact, it might already be available and you just aren't using it. For example, Perforce streams allow in-place branching.

  • 1
    Note, that CVS had branches as separate concept from directories.
    – Jan Hudec
    Aug 14, 2014 at 11:28
  • 1
    Subversion was able to switch branches in a checkout since early versions using svn switch.
    – Jan Hudec
    Aug 14, 2014 at 11:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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