Fun fact: it’s possible to make a fully distributed version control system that maintains complete history of every branch at all times, down to the individual keystrokes if necessary, on large projects, in realtime, and have it be fast. It can even be peer-to-peer, and operate over an unreliable mesh network, if you like. When people start arguing that version control systems can’t do something with reasonable performance, they’re usually dead wrong.
Think of it this way: Vim undo history is a tree which you can walk visiting every branch (not that it’s a thing you want to do). Now, writing all this data out has some cost in IO bandwidth—comparable to bandwidth of the keyboard, i.e. kBytes/minute. Vim users don’t notice the cost of maintaining the tree in RAM.
Synchronising it at first opportunity is also not hard if you do it in the background and so latency can be tolerated most of the time.
The merges.. you can try to do them mostly on marked commits, and then they can be done just like they are done now.
But implementing all that is a great undertaking, to be sure.
Wait—vim undo is a tree? So I can get back the revisions that I lost by undoing the last 100 operations and then carelessly inserting a character? HOW?
An unreleased, not production-ready VCS that I made so I could finish grad school. :-)
The basic approach is similar to how git works: store all your revision state as a tree, and have code for merging trees. If you choose a good representation for this tree, and take some care with how you implement the merging operations, and do the merge in such a way that you’re guaranteed to achieve convergence regardless of merge order, then you can get all those snazzy properties I mentioned earlier.
I’ve proven asymptotic time bounds and correctness for all the operations, and verified that it actually works the way it’s supposed to in real code, but for now this is of mostly theoretical interest. For now.
Fun fact: it’s possible to make a fully distributed version control system that maintains complete history of every branch at all times, down to the individual keystrokes if necessary, on large projects, in realtime, and have it be fast. It can even be peer-to-peer, and operate over an unreliable mesh network, if you like. When people start arguing that version control systems can’t do something with reasonable performance, they’re usually dead wrong.
That sounds amazingly cool. What version control system(s) are you thinking of, there?
It looks like an estimation, not a VCS link.
Think of it this way: Vim undo history is a tree which you can walk visiting every branch (not that it’s a thing you want to do). Now, writing all this data out has some cost in IO bandwidth—comparable to bandwidth of the keyboard, i.e. kBytes/minute. Vim users don’t notice the cost of maintaining the tree in RAM.
Synchronising it at first opportunity is also not hard if you do it in the background and so latency can be tolerated most of the time.
The merges.. you can try to do them mostly on marked commits, and then they can be done just like they are done now.
But implementing all that is a great undertaking, to be sure.
Wait—vim undo is a tree? So I can get back the revisions that I lost by undoing the last 100 operations and then carelessly inserting a character? HOW?
Wow! It is? I had no idea!
From the looks of it this script might be a helpful way to use the feature.
Well, now that you new that it is there, you could just type :help undo-tree. Basically, it is about g+/g-.
And the next chapter of undo.txt tells you about saving undo history.
The limiting case of merge frequency is to do a branch and merge on every keystroke, and create something like Etherpad. This is completely practical.
Ooh, I hadn’t thought about it that way—sure, it’d take thousands of those to clog a modern high-speed connection.
An unreleased, not production-ready VCS that I made so I could finish grad school. :-)
The basic approach is similar to how git works: store all your revision state as a tree, and have code for merging trees. If you choose a good representation for this tree, and take some care with how you implement the merging operations, and do the merge in such a way that you’re guaranteed to achieve convergence regardless of merge order, then you can get all those snazzy properties I mentioned earlier.
I’ve proven asymptotic time bounds and correctness for all the operations, and verified that it actually works the way it’s supposed to in real code, but for now this is of mostly theoretical interest. For now.