I got into unix after CVS had pretty much displaced SCCS and RCS, but the older per-file version control systems persisted long enough that I had a few close encounters with them.
When I took over Cambridge University’s DNS, its code and configuration was still in SCCS, because that was what shipped with SunOS in 1991ish. I converted the SCCS archive via RCS and CVS to git which was a fairly entertaining exercise. (Sadly the links in that blog post are mostly broken.) I even used those conversion scripts more than once! (That repository ended up with at least three distinct root commits, one for the main DNS history, one for the Ansible setup that started with DHCP and later grew to handle DNS too, and later the separate vanity domain DNS setup.)
This avoid conflicts that would occur when using the normal context-based diff/merge algorithms, because if you extract a line from a hunk and move it to an ancestor, then it’s likely that the remaining hunk will n no longer apply because the context no longer matches.
The email mentions that you can fetch an arbitrary version of the file in “constant time”, which sounds misleading. You have to traverse the entire weave regardless of what revision you want, so older versions are fetched in the same amount of time as newer versions, but it means that the operation scales linearly in the size of the file’s weave/history. For this reason, it’s probably not suitable as a primitive for modern, scalable source control systems.
I got into unix after CVS had pretty much displaced SCCS and RCS, but the older per-file version control systems persisted long enough that I had a few close encounters with them.
When I took over Cambridge University’s DNS, its code and configuration was still in SCCS, because that was what shipped with SunOS in 1991ish. I converted the SCCS archive via RCS and CVS to git which was a fairly entertaining exercise. (Sadly the links in that blog post are mostly broken.) I even used those conversion scripts more than once! (That repository ended up with at least three distinct root commits, one for the main DNS history, one for the Ansible setup that started with DHCP and later grew to handle DNS too, and later the separate vanity domain DNS setup.)
Sapling uses a weave-like mechanism to implement line-based merging for
sl absorb: https://sapling-scm.com/docs/dev/internals/linelogThis avoid conflicts that would occur when using the normal context-based diff/merge algorithms, because if you extract a line from a hunk and move it to an ancestor, then it’s likely that the remaining hunk will n no longer apply because the context no longer matches.
The email mentions that you can fetch an arbitrary version of the file in “constant time”, which sounds misleading. You have to traverse the entire weave regardless of what revision you want, so older versions are fetched in the same amount of time as newer versions, but it means that the operation scales linearly in the size of the file’s weave/history. For this reason, it’s probably not suitable as a primitive for modern, scalable source control systems.