

What Every CEO Need to Know about Distributed Version Control Systems - jdwyah
http://blog.jdwyah.com/2014/12/what-every-ceo-need-to-know-about.html

======
dalke
The Biblical allusion to "In the beginning", was a very long time ago. SCCS,
the first version control system for Unix, started in the 1970s. VMS used the
Files-11 file system, with built-in file versioning.

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...](http://www.neurophys.wisc.edu/comp/docs/oper/dspace.html#userd)
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.

~~~
jdwyah
(author of the post here)

Dropbox et al all solve the fundamentals quite well. And yes, sure OpenBSD etc
all got built pre-git.

The thing I'm trying to highlight is the cultural effects of something like
GitHub on how organizations function. When you can subscribe to user commit
histories, and pull requests comments are built in I do think something
'magic' happens that leads to a solution much greater than its constituent
parts (versioning/branching/network-shares/etc).

A public, recorded, specific conversation emerges out of GitHub that I think
is simply different from what's come before it.

For businesses in particular I think the move to distributed information will
necessitate moving away from the concept of Docs & PPT that currently form the
backbone of communication. Smaller components of thought work better in a DVCS
and I think businesses will want to conform to that model.

~~~
dalke
Your thoughts may be true, but the scenarios you gave didn't explain how
subscribing to user commit histories and pull requests comments connect to
evaluating a P&L, changing the marketing and communications theme, or editing
sales documents.

Instead, you require a migration to an entirely different system (which you
haven't described) without MS Word documents and Powerpoint presentations in
order to achieve that magic.

How much time will it be until a DVCS-assisted document editor can manage the
fine-grained UI presentation of something like MS's "Track Changes" for Word?

