Live data from Hacker News

History of version control - 10 astonishments

flourish.org

21–30 of 76 posts

Re: History of version control - 10 astonishments

#21
There are actually a number of historians looking at version/source control (although there still remains a dearth of study, given the importance of the issue). Michael Mahoney, Michael Cusumano, and N.L. Esmenger are three of the more important. For a contextualization of the history, see my short presentation (at UCLA): http://www.iqdupont.com/networked-modes-of-production/

Re: History of version control - 10 astonishments

#22
Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

Re: History of version control - 10 astonishments

#23
post #22

Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

I used SourceSafe for the better part of 10 years. The underpinning technology very much resembled RCS.

But all-in-all, it was quite serviceable for a 75,000 line C++ project. Just don't try to do branches.

Re: History of version control - 10 astonishments

#24
I don't know what the date would be, but I think somewhere before "you can keep lots of versions in one file" should go "you can keep lots of versions of one file" -- a versioning file system. Not sure when this was introduced; Wikipedia thinks it may have been in ITS.

I used to work on a large Lisp system where our entire source control system was provided by Emacs versions and locking on a central NFS server, with some explicit branching support in the build code, and with version freezing done by copying directories. I can hear you gagging, dear reader, but actually it didn't work that badly, except that it didn't handle distributed development.

Re: History of version control - 10 astonishments

#25
post #22

Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

Is there any vcs that would be better than any other when it comes to a serious EMI issue? And, who wraps an ethernet cable around a switch mode power supply brick?

Re: History of version control - 10 astonishments

#26
post #8
post #6

Earlier quoted context omitted.

Monotone gave most inspiration according to the authors of git and hg. But the author addresses the point anyway: > I’m not recording the first time anyone made the astonishing thing, but the first time it was productised and became popular.

Torvalds was expressly trying to replace bitkeeper when he wrote git. And I'm not sure anything he said about other systems might be considered "inspiration". But that said, git really isn't very similar to bitkeeper except insofar as it enables distributed development. Both model development as a forest of independent developer trees which communicate with each other through merges. But bitkeeper is still a traditio…

According to Wikipedia[1], he liked some of its features, and seemed to float it as a model for a replacement.

[1] http://en.wikipedia.org/wiki/Monotone_(software)#Monotone_as...

Re: History of version control - 10 astonishments

#27
post #12
post #10

Earlier quoted context omitted.

It gives very short shrift to commercial source control systems generally. Two (VSS, and SCCS --- the latter part of the original AT&T Unix distributions, on the same closed-source terms) get mentioned in passing, but neither gets treated as a milestone. That would include BitKeeper --- copies were available for a few years at no cost to Linux kernel developers, but only on increasingly restrictive terms, which McVoy…

Misses also GOOG's dearly Perforce.

I believe perforce handles large binaries as well.

Re: History of version control - 10 astonishments

#28
post #25
post #22

Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

Is there any vcs that would be better than any other when it comes to a serious EMI issue? And, who wraps an ethernet cable around a switch mode power supply brick?

Yes, almost any other VCS would fare better. VSS was set up so that clients could write files directly into the repository -- if the client failed for whatever reason, the repository file could get corrupted.

Re: History of version control - 10 astonishments

#29
It is interesting to me that Subversion barely gets a mention. There should be a 7.5 which is along the lines of:

cvs was great and all, but we couldn't version our directories, branching and merging was a mess, the wire protocol was hard to use, it had a ton of security holes and the storage format took up too much space. So, Subversion was created as a way to do a better cvs, without thinking about the larger intrinsic issues with the current state of version control. Thus, missing the whole 'distributed' boat and letting Linus eat our lunch.

Note: I worked at CollabNet during this time and watched a lot of the discussions around Subversion. I have great respect for the Subversion developers. Karl is an awesome and brilliant guy. It was a bubble, technology isn't anywhere where it is today and I think we were all misguided at that time. We all made a lot of mistakes.

Re: History of version control - 10 astonishments

#30
post #22

Ugh, SourceSafe. I worked for a company that used it. They had terrible intermittent file corruption issues. Long story short, we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick, which caused network errors over SMB which led to file corruption. Ugh.

> we tracked down the root cause -- an Ethernet cable wrapped too tightly around a power supply brick

I just became a little lightheaded, and my vision has gone all blurry and grey.

I hope you're claiming some sort of disability compensation from that company over the long term harm this must have caused you.

Post reply on HN