3 ms·
Last time I checked, the Darcs project had mostly fixed the performance issues. Shouldn't it be better to concentrate and unite their efforts?
by rhabarba 10y ago
Last time I checked, the Darcs project had mostly fixed the performance issues. Shouldn't it be better to concentrate and unite their efforts?
- WorldMaker 10y agoThis isn't the first time that an entirely different patch algebra has been tested outside of darcs itself (camp is mentioned in other posts here, darcs-2 versus darcs-1 was sort of built this way too). Sometimes it can be easier to prototype and/or try entirely different directions without a backwards compatibility liability, and then come back to the "parent" project with working code and figure out the migration strategy then. One thing I see here (as a long time reader/follower of the space) is that pijul has been using other languages than Haskell and there's some thought that a more approachable language might bring in more developers outside of the subset of Haskell developers that have been darcs' main source of development experience.
- lvh 10y agoThe challenges with darcs' performance lie at the core of its theory of patches; IIUC, there's no way to make exponential merge go away without also breaking darcs. pijul changes the theory, and does so in a way specifically to avoid slow algorithms.