1. 21
  1. 3

    I’m really excited for pijul (or whatever its latest name is) but my historical codebase is the last place I want something experimental or unstable.

    I asked this question before but the answer was no at the time: has Pijul matured sufficiently that it can import something like the Linux git repo (or a random date range of it at least) and successfully convert the revisions into a patch format?

    1. 5

      Pijul is becoming really stable. Formats haven’t changed in months, and the last non-backwards-compatible change was 8 months ago.

      We’re importing large repos fast and without a problem now, unlike a year ago where it often failed, or two years ago when it saturated the memory in one minute and had no theoretical chance of importing the first 1000 commits. Huge projects like Ruby or Python pass our conversion tests in reasonable time. Linux can probably be imported too, but since it is rather large, it isn’t part of our standard test suites.

      One remaining issue, which will be solved in the next few months, is that really large repos can end up consuming too much disk space. Nothing unreasonable, but we have plans to make these repos very small on disk.

      1. 2

        Do you mean large as in “containing individual files that are of large size” (git’s general problem) or does that include large repo history (like the FreeBSD repo, for example)?

        Is it merely a problem with exploded textual representation such that filesystem-level compression would help?

        1. 3

          Many questions:

          • Large files aren’t a problem in Pijul, their on-disk representation is (1) a compressed patch containing the contents and (2) a tiny footprint in a more complex datastructure.
          • I was really talking about large histories. Some histories might still be absolutely huge, but I believe there are very few projects with such large histories. Pijul can take inputs orders of magnitude larger than Darcs, for example. If you organise your repos cleverly, you might get away with partial clones, which work much better than in any other VCS thanks to patch commutation + fast algorithms.
          • No textual representation, but a datastructure growing linearly with the number of edits. Note the the time complexity grows logarithmically, and also most other VCS have similar problems, which they sometimes solve in interesting ways. I have a plan to make that datastructure smaller, and I was planning to wait a bit before implementing it. I’m about to announce the beta release. Depending on the feedback I receive and the number of projects that start to use Pijul, I might choose to implement that (that particular feature is a slightly ambitious project to implement).
          1. 3

            I just want to say thanks for clarifying and I wish you the best of luck. I have been cheering for Pijul from the start because I think it’s ridiculous that “store a copy of every version of every file and throw away the context of the actual changes” is the status quo.

    2. 0

      Is anything wrong with Nest lately? It seems very slow.

      1. 1

        Any particular page that feels slow? It’s proxied by Cloudflare, so there could be caching issues.