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.
8
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.
4
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.
2