4 ms·

> I think this is one of the most misleading and confusing things people seem to get taught about version control systems. Whether they store deltas or not unde

> I think this is one of the most misleading and confusing things people seem to get taught about version control systems. Whether they store deltas or not underneath is actually an irrelevant implementation detail. But surely it's easier to think of version control systems as storing version? It's right there in the name! It's not called a delta control system. Post author here! I agree! One of the fascinating bits of SCCS is that it actually exposed the idea of deltas right away to the user. Of course in the 70s, the amount of users was limited, pretty much exclusively programmers familiar with the idea, and probably all people who knew each other :). Nowdays a VCS should just care about snapshotting your work. In my experience, only Git is so confusing that people need to understand the underpinnings of the system (whats a GC, whats a tree, etc). Systems like SVN, Mercurial & Co all seem to mostly do the right thing for the user with minimal knowledge on the user side. Fun side note: I had a heated argument with Olivia Mackall, the original author of Mercurial, when I wrote Mercurial bookmarks. I initially called it refs, since they were models after git refs. Olivia insisted to call it bookmarks, since it's the more intuitive english name for what it's doing (bookmarking a part if a book of 'history'). Nowdays I much prefer the name bookmarks, since it's an analogy that makes it easy to reason about what it's doing, rather than a technical term that needs to be learned.

globular-toast 3y ago
I should have added to my original comment that I wasn't criticising the article, which I really enjoyed. Glad it was taken that way! It's really interesting that those early systems really did deal with deltas. Unbelievable that ideas from systems that have been and gone before people's lifetimes still prevail today. When was the last time users needed to know about deltas? Possibly skipping ahead impatiently here...
HexDecOctBin 3y ago
> Systems like SVN, Mercurial & Co all seem to mostly do the right thing for the user with minimal knowledge on the user side. I have an another blog idea for you: what are these "right things"? I have used Mercurial a bit when I was new to programming, and back then Git and Mercurial seemed more or less the same with different command names. Today, I almost exclusively use (and hate) Git, but I find it hard to see what alternatives there would be in DVCS space, other than something lie Darcs/Pijul (perhaps my imagination has been stunted by too much exposure to Git). It will be great to have someone with the knowledge lay it out comprehensively and explicitly, so that the next generation of VCS developers will be able to build upon it.
- steveklabnik 3y ago
  If you haven’t checked out jj yet, you may like it!
- somnium_sn 3y ago
  Thank you! Great idea! I do have thoughts about waht the next generation of source control systems should look like! It hopefully will be the last post in the full series. So estimated arrival time for that post, by interpolation of how long it took me to write this post, is roughly 1-2 years :P
- panick21_ 3y ago
  BitKeeper was open sourced. But I guess it wasn't really picked up.
  - somnium_sn 3y ago
    By the time it was open sourced, the DVCS wars were already at an end. Git (due to Github) was used everywhere. Bazaar saw it's last release in the same year as BK open sourced (2016) and Mercurial usage dropped slowly.
- pmeunier 3y ago
  IMHO there are different ways to design a version control system: 1. The SCSS/Git way, aka the hacker way: look at what we can do with existing stuff, and use that to build something that can do the job. For example if you're one of the world's expert on filesystem implementations, you can actually produce a fantastic tool like Git. 2. The mathematician's way: start by a model of what collaboration is, and expand from there. If your model is simple enough, you may have to use complex algorithms, but there is a hope that the UI will match the initial intuition even for non-technical users. Darcs did this, using the model that work produces diffs, and conflicts are when diffs can't be reordered. Unfortunately this is slow and not too scalable. Pijul does almost the same, but doesn't restrict itself to just functions, using also points in the computation, which makes it much faster (but way harder to implement and a bit less flexible, no free lunch). 3. The Hooli way: take an arbitrary existing VCS, say Git. Get one of your company's user interviewer, and try to please interviewees by tweaking the command names and arguments. The tradeoff between 1 and 2 is that 1 is much more likely to produce a new usable and scalable system fast, but may result in leaky abstractions, bad merges and hacks everywhere, while 2 may have robust abstractions if the project goes to completion, but that may take years. OTOH, method 3 is the fastest and safest method, but may not produce anything new. So, I am the main author of Pijul, and I also don't quite see how to do much better (I'm definitely working on improvements, but not technically radical). But the causal relationship isn't the one you may be thinking: it is because I thought this was the ultimate thing we could have that I started the project, not the other way around.
moomin 3y ago
Arguably git still does this: quite a lot of the implementation is exposed to the user. But, as someone who learned RCS: that paper was exceptionally clear and the whole thing was extremely comprehensible, right down to the ,v format being human readable. In retrospect VCS had a long way to go, but going from nothing to RCS was huge.

globular-toast 3y ago

I should have added to my original comment that I wasn't criticising the article, which I really enjoyed. Glad it was taken that way! It's really interesting that those early systems really did deal with deltas. Unbelievable that ideas from systems that have been and gone before people's lifetimes still prevail today. When was the last time users needed to know about deltas? Possibly skipping ahead impatiently here...

HexDecOctBin 3y ago

> Systems like SVN, Mercurial & Co all seem to mostly do the right thing for the user with minimal knowledge on the user side. I have an another blog idea for you: what are these "right things"? I have used Mercurial a bit when I was new to programming, and back then Git and Mercurial seemed more or less the same with different command names. Today, I almost exclusively use (and hate) Git, but I find it hard to see what alternatives there would be in DVCS space, other than something lie Darcs/Pijul (perhaps my imagination has been stunted by too much exposure to Git). It will be great to have someone with the knowledge lay it out comprehensively and explicitly, so that the next generation of VCS developers will be able to build upon it.

steveklabnik 3y ago
If you haven’t checked out jj yet, you may like it!
somnium_sn 3y ago
Thank you! Great idea! I do have thoughts about waht the next generation of source control systems should look like! It hopefully will be the last post in the full series. So estimated arrival time for that post, by interpolation of how long it took me to write this post, is roughly 1-2 years :P
panick21_ 3y ago
BitKeeper was open sourced. But I guess it wasn't really picked up.
- somnium_sn 3y ago
  By the time it was open sourced, the DVCS wars were already at an end. Git (due to Github) was used everywhere. Bazaar saw it's last release in the same year as BK open sourced (2016) and Mercurial usage dropped slowly.
pmeunier 3y ago
IMHO there are different ways to design a version control system: 1. The SCSS/Git way, aka the hacker way: look at what we can do with existing stuff, and use that to build something that can do the job. For example if you're one of the world's expert on filesystem implementations, you can actually produce a fantastic tool like Git. 2. The mathematician's way: start by a model of what collaboration is, and expand from there. If your model is simple enough, you may have to use complex algorithms, but there is a hope that the UI will match the initial intuition even for non-technical users. Darcs did this, using the model that work produces diffs, and conflicts are when diffs can't be reordered. Unfortunately this is slow and not too scalable. Pijul does almost the same, but doesn't restrict itself to just functions, using also points in the computation, which makes it much faster (but way harder to implement and a bit less flexible, no free lunch). 3. The Hooli way: take an arbitrary existing VCS, say Git. Get one of your company's user interviewer, and try to please interviewees by tweaking the command names and arguments. The tradeoff between 1 and 2 is that 1 is much more likely to produce a new usable and scalable system fast, but may result in leaky abstractions, bad merges and hacks everywhere, while 2 may have robust abstractions if the project goes to completion, but that may take years. OTOH, method 3 is the fastest and safest method, but may not produce anything new. So, I am the main author of Pijul, and I also don't quite see how to do much better (I'm definitely working on improvements, but not technically radical). But the causal relationship isn't the one you may be thinking: it is because I thought this was the ultimate thing we could have that I started the project, not the other way around.

moomin 3y ago

Arguably git still does this: quite a lot of the implementation is exposed to the user. But, as someone who learned RCS: that paper was exceptionally clear and the whole thing was extremely comprehensible, right down to the ,v format being human readable. In retrospect VCS had a long way to go, but going from nothing to RCS was huge.