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!

    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.

          1. 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.

                1. 4

                  What is the purpose of this post, other than simply pasting the original header file? Even the comments were already in the original header file. Why wouldn’t you simply link to the original header file, if there is nothing to be added?

                  For those who can read C, the original git commit (which is actually extremely simple): https://github.com/git/git/tree/e83c5163316f89bfbde7d9ab23ca2e25604af290

                  1. 6

                    The purpose of the post is to get people curious about looking under the hood at Git’s code (which was very interesting to me). It is also to help clarify an aspect of how Git’s code works - the header file. The original header file does have comments, but they tend to be on the technical side. I expanded on those to help (esp newer folks) better understand how it works and to provide some context for the structures that are created.

                    As you mention, another approach would have been to write out my comments as points in the article itself and link back to the original version. But it helped me learn to go through and document the code in this way (esp in the context of the rest of the codebase), so I decided to make that available.

                    1. 5

                      My apologies, I was too quick with my judgement. You actually did add comments in the source code. Well done, they felt like they were there already.

                      1. 2

                        No problem, and thank you :)

                  1. 4

                    I wrote this a long time back about the evolution of version control systems. I think it is a bit more broader than this one, while perhaps not as deep.

                    1. 2

                      Just read it. This is an excellent article - thanks for sharing. The descriptions are extremely clear and well written. I think yours gets a little more into how the design principles of each RCS affect the usage, whereas mine touches a little more on how/where the revision data is stored and what it looks like sitting on the filesystem.

                      1. 2

                        Thanks! much appreciated.

                    1. 5

                      In this article, we provided a technical comparison of some historically relevant version control systems. If you have any questions or comments, feel free to reach out to jacob@initialcommit.io.

                      No Fossil. sniff

                      I reached out (since I was feeling open – ahem! – free)

                      1. 6

                        Hey appreciate you reaching out @lettucehead! I poked around on the Fossil website and the integrations look pretty sweet. I installed it and will hopefully get some time to play around with it this week. Hopefully will add a section into the blog post in the near future.

                        p.s. I’m just learning the ropes here, but I submitted a hat request as the creator of the Initial Commit site.

                        1. 1

                          nice!!!