5 ms·

How does it compare to Darcs? https://hackage.haskell.org/package/darcs https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ http:

by hbbio 7y ago

How does it compare to Darcs? https://hackage.haskell.org/package/darcs https://hackage.haskell.org/package/darcs Edit: Better link is http://darcs.net/ http://darcs.net/, darcs has been around for more than 10 years and is still actively maintained.

superpermutat0r 7y ago
I think it has a more tractable algorithm than darcs.
mattmein 7y ago
https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
pmeunier 7y ago
From a complexity theory perspective, the Darcs patch application algorithm runs in time O(2^n) in the worst case, where n is the number of patches since the beginning of the repository. That exponential merge happens in practice. In Pijul, it is always O(log n + c), where c is the size of the largest conflict between the current repository and the patch you're trying to apply. So, it is a double-exponential improvement in practical uses, even though you could totally make c = n for the sake of the argument. The tradeoff is that Pijul doesn't handle the very cool (but rarely usable in practice) "darcs replace". From an implementation perspective, Pijul is in Rust, relies on less external stuff than Darcs (for example no need for Putty on Windows), is available as a library. edit: also, Pijul has branches, too, and Darcs doesn't. But branches are far from being as useful as in Git, and in fact most Git workflows use short-lived branches, which are essentially just patches in both Pijul and Darcs.
- carterschonwald 7y ago
  Are we talking about the Darcs version < 2 merge algorithm or the merge algorithm in current darcs?
  - pmeunier 7y ago
    The current darcs. Conflict fights are still exponential, and happen sometimes. I'm a really happy darcs user, but I was talking about complexity theory here, which considers worst cases. For the sake of completeness, I don't know the full story for the complexity of Darcs "in most cases", but I believe it to be linear in the size of history in the normal case (as it needs to try and commute all the patches with your new patch).
    - gnufx 7y ago
      "Current" might mean the latest release or the current darcs.net repo with v3 patches, which I can't claim to have followed.
- gnufx 7y ago
  I can't find the details off-hand, but doesn't Darcs actually have the facility to define different types of patches as well as normal ones and "replace"? I don't know whether that's ever been done, but it could be useful, whether or not it's a worthwhile trade-off.
atombender 7y ago
I don't know too much about the specifics, but Pijul is based on a new "theory of patches" that is different from Darcs' and which they claim is "formally correct". Darcs always had a problem with exponential merge solutions, and Pijul apparently doesn't, partly thanks to using what they call a "conflict-tolerant" format for storing the tree. See the "Pijul for Darcs uses" at https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html.
cryptonector 7y ago
It's comparable, apparently: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...
core-questions 7y ago
The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.
- pmeunier 7y ago
  Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh (https://cargo.io/crates/thrussh https://cargo.io/crates/thrussh), which aim at making the UX as smooth as possible.
  - the_duke 7y ago
    Correct url: https://crates.io/crates/thrussh https://crates.io/crates/thrussh
  - core-questions 7y ago
    Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement. Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix. I am interested in https://www.unisonweb.org/ https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.
vmchale 7y ago
Darcs has a some pathological algorithms. IME, darcs has never lost a repo of mine and Pijul has. So I'm not clamoring to use pijul instead - I don't use darcs in a way that runs into the pathological cases anyway.
- pmeunier 7y ago
  In full fairness, was it Darcs version 0.x? Pijul has never made any claim to be stable yet (but we're getting there).
  - vmchale 7y ago
    Nope! But I need reliable version control, so I will continue using darcs until I hear Pijul is more reliable.

by hbbio 7y ago

superpermutat0r 7y ago

I think it has a more tractable algorithm than darcs.

mattmein 7y ago

https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...

pmeunier 7y ago

From a complexity theory perspective, the Darcs patch application algorithm runs in time O(2^n) in the worst case, where n is the number of patches since the beginning of the repository. That exponential merge happens in practice. In Pijul, it is always O(log n + c), where c is the size of the largest conflict between the current repository and the patch you're trying to apply. So, it is a double-exponential improvement in practical uses, even though you could totally make c = n for the sake of the argument. The tradeoff is that Pijul doesn't handle the very cool (but rarely usable in practice) "darcs replace". From an implementation perspective, Pijul is in Rust, relies on less external stuff than Darcs (for example no need for Putty on Windows), is available as a library. edit: also, Pijul has branches, too, and Darcs doesn't. But branches are far from being as useful as in Git, and in fact most Git workflows use short-lived branches, which are essentially just patches in both Pijul and Darcs.

carterschonwald 7y ago
Are we talking about the Darcs version < 2 merge algorithm or the merge algorithm in current darcs?
- pmeunier 7y ago
  The current darcs. Conflict fights are still exponential, and happen sometimes. I'm a really happy darcs user, but I was talking about complexity theory here, which considers worst cases. For the sake of completeness, I don't know the full story for the complexity of Darcs "in most cases", but I believe it to be linear in the size of history in the normal case (as it needs to try and commute all the patches with your new patch).
  - gnufx 7y ago
    "Current" might mean the latest release or the current darcs.net repo with v3 patches, which I can't claim to have followed.
gnufx 7y ago
I can't find the details off-hand, but doesn't Darcs actually have the facility to define different types of patches as well as normal ones and "replace"? I don't know whether that's ever been done, but it could be useful, whether or not it's a worthwhile trade-off.

atombender 7y ago

I don't know too much about the specifics, but Pijul is based on a new "theory of patches" that is different from Darcs' and which they claim is "formally correct". Darcs always had a problem with exponential merge solutions, and Pijul apparently doesn't, partly thanks to using what they call a "conflict-tolerant" format for storing the tree. See the "Pijul for Darcs uses" at https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html.

cryptonector 7y ago

It's comparable, apparently: https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html https://pijul.org/manual/why_pijul.html#pijul-for-darcs-users https://pijul.org/manual/why_pijul.html#pijul-for-darcs-user...

core-questions 7y ago

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.

pmeunier 7y ago
Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh (https://cargo.io/crates/thrussh https://cargo.io/crates/thrussh), which aim at making the UX as smooth as possible.
- the_duke 7y ago
  Correct url: https://crates.io/crates/thrussh https://crates.io/crates/thrussh
- core-questions 7y ago
  Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement. Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix. I am interested in https://www.unisonweb.org/ https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.

vmchale 7y ago

Darcs has a some pathological algorithms. IME, darcs has never lost a repo of mine and Pijul has. So I'm not clamoring to use pijul instead - I don't use darcs in a way that runs into the pathological cases anyway.

pmeunier 7y ago
In full fairness, was it Darcs version 0.x? Pijul has never made any claim to be stable yet (but we're getting there).
- vmchale 7y ago
  Nope! But I need reliable version control, so I will continue using darcs until I hear Pijul is more reliable.