Live data from Hacker News

History of version control - 10 astonishments

flourish.org

31–40 of 76 posts

Re: History of version control - 10 astonishments

#31
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.

Google's Perforce?

Re: History of version control - 10 astonishments

#32
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.

Back in the late 1990s, my team's SourceSafe repository would get corrupted weekly. Like your experience, using SMB over a slow network seemed to have a 50% chance of corrupting the repo. SourceSafe was worse than no source control...

Re: History of version control - 10 astonishments

#33
post #28
post #25

Earlier quoted context omitted.

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.

And salvaging a corrupted repository was a pain because SourceSafe stored your files in a munged format spread across dozens of files named aaaaaaaa, aaaaaaab, aaaaaaac, and so on. :(

Re: History of version control - 10 astonishments

#34
post #28
post #25

Earlier quoted context omitted.

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.

The bad memories are coming back. IIRC you would mount a network drive containing the VSS files. One company I worked for had a virus which infected the repository and I don't think it was ever completely cleaned out.

Re: History of version control - 10 astonishments

#35

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/

Scholarship of this kind is important as it gathers secondary references for future works of synthesis as well as preventing the repetition of mistakes!

Is anyone doing a decent work of synthesis for the history of computing in general? Something like Judt/Postwar or TARUSKIN/History of Western Music?

Re: History of version control - 10 astonishments

#36
post #18
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…

It also completely ignores earlier distributed source control projects like GNU Arch. 2005 was when there was an open source distributed VCS that was fast and pleasant to use, but implementations of the idea are older than that.

Darcs merits a nod, as well.

Re: History of version control - 10 astonishments

#38

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 intri…

The article is about astonishment. Everything SVN did was fairly obvious.

Re: History of version control - 10 astonishments

#39
post #14
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…

In terms of historical interest, it's also worth noting why McVoy restricted and eventually withdrew the BitKeeper license: Andrew Tridgell (of Samba and rsync) had begun reverse-engineering the protocol with the eventual intent of implementing a free client. The resulting debacle was fairly ridiculous; Linux chastising Andrew Tridgell, continued flamewars about using a closed-source product. What I find interesting…

Well if I recall correctly his reverse "engineering" consisted of figuring out that the protocol was a plain-text English based protocol (i.e it would be like if you were to reverse engineer FTP by looking at the TCP stream).

Re: History of version control - 10 astonishments

#40

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 intri…

The article is about astonishment. Everything SVN did was fairly obvious.

Ha! Definitely can't argue that point. ;-)
Post reply on HN