3 ms·

It presents the same conceptual UI as Darcs (it's patch-based, not snapshot-based), but provides the performance of Git and Mercurial. It does that by changing

by gecko 11y ago

It presents the same conceptual UI as Darcs (it's patch-based, not snapshot-based), but provides the performance of Git and Mercurial. It does that by changing the internal storage of how patches work compared to Darcs. If you know Darcs, that's your entire sales pitch: Darcs, but now performant. For everyone else: In Git and Mercurial (and Bazaar, Monotone, Subversion, tla, Fossil, TFS2, and others I'm forgetting), the state is always represented conceptually as a snapshot of the current revision and a pointer to the snapshot of previous revision or revisions, so if you identify that you're at "snapshot 590", and I'm also at "snapshot 590", we're both at the same thing, and both have exactly the same history of how we got there. In a patch-based system, like Pijul or Darcs, that's not true. The state is instead represented by the set of applied patches. These usually have an implicit ordering, but you and I can theoretically have the same patches applied and have a different ordering. (We also can briefly have different resolutions to merge conflicts that result from that, and Darcs' historical inability to deal efficiently with you and me resolving conflicts differently is a major reason it doesn't scale well.) That sounds weird, but can have major benefits. For example, I can now sanely cherry-pick a bug fix from you regardless of the history of that bugfix--and, unlike in Git and Mercurial, Darcs/Pijul will know that the patch I cherry-picked from you is the exact same one that you have on your branch. No duplication, Cherry-Pick: messages, or merge collisions will result if I later pull in your whole branch (or vice-versa). You can also do things like have a patch that has all of your security settings, but always simply not push that when you push out to a public server. (N.B., giving this as an example, not best-practice.) If Pijul works, and can provide Darcs' model in an efficient way, it'd be really awesome. I'm not sure whether it'd be better than Mercurial or Git's model at scale, but it's been really hard to answer that question historically when Darcs itself didn't scale well. Pijul could change that.

jerf 11y ago
"That sounds weird, but can have major benefits." I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. It never comes up in SVN or similarly klunky systems, because they're too incidentally complex to notice the underlying essential mismatch. Git and friends, to their credit, made the incidental complexity go away, but I think the essential complexity of their approach is still higher than it ought to be. I wish pijul all the best, because there is room for improvement here. And may I suggest to the pijul team that they really, really want a Pijul-hub as soon as they think they're even remotely ready.
- gecko 11y ago
  I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. I actually agree. I advocated for DVCS-based workflows for a long time, but I think it speaks volumes that I "got" Darcs within about 20 minutes of first seeing it and playing with it, but I know for a fact that, somewhere in the Freenode archives, you can find me saying "The frak is Mercurial? The frak is Git? The frak is this?" as I tried to grok what on Earth they were doing--and this after having taught myself tla! That said, just because something is intuitive doesn't necessarily mean that something is best engineering discipline. I want a Darcs-like workflow to be the dominant one specifically because it's intuitive, but I'm very open to the fact that it might be a really, really crappy way to build a sane (forget performant) large code base. Or it may be exactly what we've always wanted. The simple fact is that I have no idea. This industry, for all the "science" in CS, has got to be the least results-based discipline I'm personally aware of. Pijul will at least permit anecdotal tests of how well patch-based systems scale as a workflow if it takes off, but I'm not holding my breath on someone doing a genuine A/B productivity/trade-off study.

by gecko 11y ago

jerf 11y ago

"That sounds weird, but can have major benefits." I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. It never comes up in SVN or similarly klunky systems, because they're too incidentally complex to notice the underlying essential mismatch. Git and friends, to their credit, made the incidental complexity go away, but I think the essential complexity of their approach is still higher than it ought to be. I wish pijul all the best, because there is room for improvement here. And may I suggest to the pijul team that they really, really want a Pijul-hub as soon as they think they're even remotely ready.

gecko 11y ago
I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. I actually agree. I advocated for DVCS-based workflows for a long time, but I think it speaks volumes that I "got" Darcs within about 20 minutes of first seeing it and playing with it, but I know for a fact that, somewhere in the Freenode archives, you can find me saying "The frak is Mercurial? The frak is Git? The frak is this?" as I tried to grok what on Earth they were doing--and this after having taught myself tla! That said, just because something is intuitive doesn't necessarily mean that something is best engineering discipline. I want a Darcs-like workflow to be the dominant one specifically because it's intuitive, but I'm very open to the fact that it might be a really, really crappy way to build a sane (forget performant) large code base. Or it may be exactly what we've always wanted. The simple fact is that I have no idea. This industry, for all the "science" in CS, has got to be the least results-based discipline I'm personally aware of. Pijul will at least permit anecdotal tests of how well patch-based systems scale as a workflow if it takes off, but I'm not holding my breath on someone doing a genuine A/B productivity/trade-off study.