
VCS based on categorical theory of patches (2017) - qrv3w
https://jneem.github.io/merging/
======
alephnan
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.

~~~
gnufx
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](http://liamoc.net/posts/2015-11-10-patch-theory.html)

------
colanderman
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...](https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory)

~~~
gnufx
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?

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

------
louthy
This is very nicely written. Isn't the principle essentially similar to vector
clocks? It certainly _feels_ very similar.

~~~
euyyn
What's a vector clock?

~~~
wolfgke
> What's a vector clock?

[https://en.wikipedia.org/wiki/Vector_clock](https://en.wikipedia.org/wiki/Vector_clock)

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

