VCS based on categorical theory of patches (2017)(jneem.github.io)
jneem.github.io
VCS based on categorical theory of patches (2017)
https://jneem.github.io/merging/
10 comments
Are there any endeavors to decouple VCS interface from the implementation? An analogy is LLVM, but for VCS, in terms of modularizing the architectural layers. It’s difficult justifying learning a new VCS when popular open source projects and employers select for particular systems. Surely there are tradeoffs, but enabling developers to use a familiar interface such as Git would reduce the friction of adoption, while still providing the benefits associated with a particular implementation that’s suited for the project.
Probably not what you mean, but there's an alternative patch theory implementation as a Haskell library: http://liamoc.net/posts/2015-11-10-patch-theory.html
That's a lot of text not to mention Darcs, which I believe introduced the "unordered set of patches merged by mathematical theorem" [1] 15 years ago.
I was a heavy Darcs user for a while before switching to Git. The biggest flaw in the "set-of-patches" model IMHO is the inability to quickly compare the state of two repositories. With Git, this is trivial -- since commit hashes represent the entire history, just compare them. With a Darcs-style VCS, you're limited to only comparing patch sets that have been explicitly tagged, or comparing the repositories patch by patch. And the existence of rebasing (which is sometimes necessary even in Darcs-style repos) pretty much negates the main benefit of the set-of-patches model.
[1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
I was a heavy Darcs user for a while before switching to Git. The biggest flaw in the "set-of-patches" model IMHO is the inability to quickly compare the state of two repositories. With Git, this is trivial -- since commit hashes represent the entire history, just compare them. With a Darcs-style VCS, you're limited to only comparing patch sets that have been explicitly tagged, or comparing the repositories patch by patch. And the existence of rebasing (which is sometimes necessary even in Darcs-style repos) pretty much negates the main benefit of the set-of-patches model.
[1] https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
Yes, I don't understand why Pijul didn't re-implement the guts under basically the Darcs interface rather than re-doing it all. It's not obvious that it wouldn't fit.
I don't understand the comparing repos requirement. if I'm comparing Darcs branches it's going to be for the presence or absence of certain patches; what else do you normally need? Also, how does Darcs' rebasing negate the benefits of the model?
I don't understand the comparing repos requirement. if I'm comparing Darcs branches it's going to be for the presence or absence of certain patches; what else do you normally need? Also, how does Darcs' rebasing negate the benefits of the model?
> I don't understand the comparing repos requirement. if I'm comparing Darcs branches it's going to be for the presence or absence of certain patches; what else do you normally need?
It's a lot easier to tell someone "I have commit 94ba73df, check that out", than to send them a list of 10,000 patches they ought to have.
> Also, how does Darcs' rebasing negate the benefits of the model?
What I mean is, the fact that Git (or Mercurial, or whatever) has rebasing mostly negates the benefits of the Darcs model (since it's nearly as easy to move patches around), and does so without adding any complexity, since it's not like you can do away with rebasing entirely in Darcs anyway.
It's a lot easier to tell someone "I have commit 94ba73df, check that out", than to send them a list of 10,000 patches they ought to have.
> Also, how does Darcs' rebasing negate the benefits of the model?
What I mean is, the fact that Git (or Mercurial, or whatever) has rebasing mostly negates the benefits of the Darcs model (since it's nearly as easy to move patches around), and does so without adding any complexity, since it's not like you can do away with rebasing entirely in Darcs anyway.
This is very nicely written. Isn't the principle essentially similar to vector clocks? It certainly feels very similar.
What's a vector clock?
> What's a vector clock?
https://en.wikipedia.org/wiki/Vector_clock
https://en.wikipedia.org/wiki/Vector_clock
The principle is very general. Colimits are the essence of gluing pieces of data together so they appear just about everywhere in mathematics in some form or another. Vector clocks do form an instance of colimits. A special kind in fact, a colimit of a partially ordered set of objects.
There is a fundamental lemma of category theory that says that you can always embed a category into a larger one that allows all colimits, i.e. gluing constructions (subject to cardinality considerations).
There is a fundamental lemma of category theory that says that you can always embed a category into a larger one that allows all colimits, i.e. gluing constructions (subject to cardinality considerations).
That was weird: an hour ago I was reading "Version Control with Git" about merging and thinking "Hey, this is all just category theory", I then have a look at HN, and see this.