4 ms·

> 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

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

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.