1. 32
  1. 8

    Nice article. I cut my teeth on Apple’s internal Projector system; dunno when it was introduced, but it was already there when I started in 1991, and was used until the late 90s when everything was gradually imported into this “CVS” tool the new NeXT overlords brought with them. Projector was CVS-like. What I remember most was its terrible merging: it originally had no 3-way merge, so all competing changes had to be merged by hand! My AppleScript co-worker Wm. Cook got frustrated enough to write a 3-way merge script (in MPW shell) which eventually became a standard part of the workflow though it was never integrated into the tool itself.

    When I was briefly at Sun in 1997-98 I was introduced to a system they’d built atop SCCS, that was distributed in the same sense as modern 3rd generation tools. I thought it was genius the way you could have your own repo on your local machine, and how commits could be successively pushed into dev/integration/build servers. Back at Apple I told my co-workers about this awesome idea, but resigned myself to CVS and then SVN. So I was very happy when the 3rd-gen systems like Monotone, Darcs and Mercurial started to appear in the wild in the early 00s.

    1. 4

      Very cool! Glad you enjoyed it! I find it very interesting to hear about the internal solutions that companies devise to fill the tooling gaps in their workflows.

      Luckily CVS is before my time so I never had to experience the pain of a brutal merge with it on a real project (and it sounds like Projector was even more painful). I just set up some test projects with CVS, played with it, peeked until the hood, and consulted my buddy Teknikal_Domain to get a feel for how it works.

      Despite the negative sentiment (generally frustration) that the older tools tend to evoke, I was surprised to find that most of the features of most of the tools seem to work very well (at least on my trivial test projects).

      I had the luxury of starting my VCS learning with Git once it was already a well-formed project. I think newer developers tend to discount (or be completely unaware of) the impact that the older tools had on this field. My eyes were opened by the influence (including direct integration and extension) that the “legacy systems” have on the newer tools. Expressing that view became a (initially unplanned) purpose of the article.

      1. 2

        I wonder, just out of curiosity: Do you think there’s any merit to the older systems like CVS and SVN? Is there anything more that we could learn from them, or for the most part are they obsolete and their secrets exhausted.

        1. 5

          Overall, I don’t think so. I would never go back!

          I remember a few times thinking an innovation in a new system was a bad idea, but changed my mind after using it. Like, I didn’t like how in SVN a file didn’t have a consecutively-numbered history anymore; and the “staging area” feature of git seemed needlessly over complicated. I learned better.

          I don’t find the pre-3rd gen systems interesting, because they’re not distributed. What I’m fascinated by is propagating content (documents, discussions, databases…) across a decentralized network, because I think that’s the future of the open Internet. Modern VCSs are obviously good at that, but unfortunately they’re optimized for source code (directory hierarchies of smallish line-based text files), and the amount of metadata they keep is excessive for many use cases where it’s not critical to keep a full revision history.

          1. 3

            What I’m fascinated by is propagating content (documents, discussions, databases…) across a decentralized network

            May I suggest you take a look at IPFS if you haven’t already? That sounds like something you’d enjoy playing around with.

          2. 2

            I sometimes use first generation version control, such as RCS for files I only work on (configuration files, html documents, etc.). The main benefit over git is that I can have multiple independently versioned files in one directory.

            Emacs has a great interface for interacting with it (vc), so I don’t have to bother with the specific commands, but still can easily browse the history, create blames and add changes.

            1. 4

              A lot of my servers have RCS guarding config files with strict locking disabled, just so I always have the ability to undo to a clean copy, and once something works I can actually describe the change out-of-band instead of making my config 80% comments as to what piece does what, why, the history of it all…

              If you’re going to do that, fun tip, create an RCS/ directory, and RCS will put all it’s ,v files in there instead of in the same directory, makes things cleaner. Especially when I have 20 different files of VCL (Varnish) and then 20 other files that are the exact same to my tired eyes.

              1. 2

                I just use Ansible to manage those config files, with the Ansible playbooks and templates in a Mercurial repo. In my experience it works far better because you have everything for a system in one place.

                1. 3

                  I looked at Ansible and Chef (and still can’t really decide which one I think is “better”), but in the end, my, err… organically-grown network is just a bit too much of an unorganized mess to properly set that up. I decided that next time I tear it down and do a full rebuild (which will be done one day), then I’ll start with those tools from the ground up instead of trying to mash them into an already existing system that really doesn’t want to change.

        2. 4

          For “internals” I find it quite superficial. There is nothing about Daarcs scalability problems which Pijul claims to fix.

          1. 6

            Me-ow! Maybe you can get a refund?

            I found the level of detail about right for a high-level historical overview. I’m sure I could dig up more information if I want… for instance this “interleaved deltas” thing SCCS used sounds fascinating.

            1. 4

              It is, from a conceptual standpoint. Unlike the successive (or “reverse”) deltas of RCS, SCCS can construct any revision in about the same amount of time because it’s only dependent on the size of the history file. Since RCS successively deltas revisions, the father back in history you go, the more you have to “un-delta” to extract a revision, and the longer that takes to perform.

              I know Wikipedia has an article on the interleaved deltas, if you want a starting point..

              1. 2

                Lol and thanks! Yes there is always a balance to strike between depth/breadth/accessibility/length. I tried to appeal to the technical side of the uber-nerd without shunning the interested novice, and added a pinch of historical context.

              2. 3

                Appreciate the feedback. I will look into that Darcs item you mentioned and consider adding a note about it. If you have any other suggestions I’d love to hear them.

              3. 3

                Hey everyone, I know I wasn’t here for the first post that went up (I was just on reddit for that), but I’m here now to help out with questions and explanations of any of the VCS systems covered. (I’ve been the one helping out behind the scenes, contributing knowledge, insights, and in this case a spare server to test with)

                Additionally, if you like this sort of thing, feel free to head over to my blog where I cover a number of things… some programming, some server stuff, some just putting way too many stickers on my laptops because it was funny.

                1. 2

                  Very good article! Are you going to talk about PlasticSCM? I’ve used it in the past because the company is from my city in Spain.

                  1. 1

                    Thank you! Glad you enjoyed it. I actually haven’t heard of PlasticSCM but I will look into it!