2 ms·
Applying a patch in Darcs usued to be in O(2^n), and now apparently O(n^2), where n is the size of history. Applying a patch in Pijul is in O(p c log n), where
by pmeunier 6y ago
Applying a patch in Darcs usued to be in O(2^n), and now apparently O(n^2), where n is the size of history.
Applying a patch in Pijul is in O(p c log n), where p is the size of the patch and c the size of the largest "deletion-insertion conflict" p is involved in, where a "deletion-insertion conflict" is a situation where Alice deletes a block of text while Bob adds stuff in that same block.
Note that this is a rough bound, since all non-conflicting operations in a patch are in O(log n), except those involved in a "deletion-insertion conflict", which are in O(c log n).
So, Pijul is in fact faster than Git for merging (and rebasing). The only tradeoff at the moment is that going arbitrarily far back in history isn't as fast as it could be (this will be fixed very soon).
- fiddlerwoaroof 6y agoInteresting, I’ve been following these systems for a while, but I didn’t realize that pijul had solved the performance issues. Is pijul’s on-disk format stable yet?
- pmeunier 6y ago> Is pijul’s on-disk format stable yet? Probably. The patch format is very unlikely to change. The repository format may change a little bit still. I'd say it's probably ok to try and learn it now, but you should maybe wait for a few weeks before using it for something serious. On the other hand, we use it for itself, and I use it personally for most of my projects.