Re:VCS based on categorical theory of patches (2017)
by gnufx on Friday April 13, 2018 @11:33AM
(#16830932)
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?
Re:VCS based on categorical theory of patches (2017)
by colanderman on Friday April 13, 2018 @07:39PM
(#16834879)
> 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.
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...