What Every CEO Need to Know about Distributed Version Control Systems

A more complicated but more correct story is that PCs come out of a different heritage. VMS admins would purge old documents when the disk was full (see http://www.neurophys.wisc.edu/comp/docs/oper/dspace.html#use... for an example) and before that point contact users to purge their own space. But PCs don't have admins the same way. Unix people learned about the tools from other Unix people, including USENIX and IEEE publications. PCs users tended to have quite different background and training. But a story which starts "you learned poor practices because of your cultural upbringing" might offend the sensibilities of a CEO. ;)

Dropbox is a modern example of a file-based networked versioning system. It keeps older versions of a file so people can go back them.

(Before going further, I have to complain bitterly: many of the examples imply that it's a good thing for workers to spend their free time - '3 in the morning' and 'Saturday afternoon' - on company work instead of one's self or family. It's very easy to go from there to the narrative that distributed version control is meant to exploit workers. Why can't these examples be "at 3 in the afternoon" and "on Tuesday"? Oh, right: because then there's network shared directories, which ruins the rest of the story.)

I'll evaluate the branching examples, to evaluate how unimportant branching really is for the goals.

0) "pull P&L statements on a Saturday afternoon"

Read-only access to an Excel file doesn't require branching, only secure access to the office network.

1) "to change our marketing and communications theme. Awake at 3 in the morning..."

A DVCS is much less useful when working with single file projects, like Word documents.

If that's in PowerPoint then branching is little different than making a new directory on the network drive and copying the PPT file there. If there's auto-versioning on the network drive then it's easier to use than a DVCS like git.

Since my Mac has built-in Time Machine, I also get auto-backups every hour or so, even for local files.

2) "Distributed branches"

Right, so I've worked on it on my own machine, and when ready I copy it to the network drive and tell collaborators the filename. This is significantly worse than a branching version control system because ...?

3) "Without a distributed system, the normal way of controlling the system is through something we call Access Control Lists"

A distributed system also has ACLs. There is such a thing as a private repo, for example.

Regarding "Access control is a crude instrument. A user can change something or they can't." That's an incomplete statement. If I have read access then I can change the file on my local machine. I just can't commit the changes to the original server. I can of course make my own CVS repo with the modifications. I'll lose distributed history tracking, but the essay doesn't give examples of why that might be useful or important.

Then again, even under a distributed system I might be prevented by the server's ACL from pushing the change on the server. There's anonymous access to read github, but not make a new repo on github. There's not even an anonymous way to make a pull request - you have to have an account on github first.

The solution proposed was "simply request a 'pull' to the maintainer, who can easily see that this is a simple change and merge it", but that's cheating. It requires a human to take the place of the ACL. If you have a human doing that then it's not much better than sending a context patch to the human via email.

If OpenBSD can somehow develop an entire OS with a distributed development environment under SVN, then perhaps things are not 'a million times better'?

I am not convinced that an auto-backup network drive like what Dropbox does can't be better for some of these scenarios than a distributed version control system.