Pijul – A free and open source distributed version control system

Why do you find it offputting? IANAL but it basically doesn't allow you to add code to (or get code from) Pijul itself and making it in another license. You can use it to store closed source code, you can host it yourself, offer it as a sevice for money, you can even create your own extensions as long as you release them AGPL...

I feel that AGPL for a product is misunderstood and pre-rejected without justification by far too many. Now, if you are developing a library, then AGPL sucks as a license for it, but for a cohesive product? Seems acceptable to me (not sure if it's my favorite choice)

Hi! Author here. The situation is slightly more complex than what you describe. Pijul was announced on the darcs blog, not by its authors, way before it was ready (about a year before). We had not really chosen a license back then, so we made the most conservative and protective choice available, and agreed to think again whenever we would have time.

Now that we've started to use Pijul for the website (about two weeks ago), we want to change the license.

I'm slightly annoyed by all the political statements in GPL3, AGPL3 and several versions of LGPL, such as "you cannot use this on impure devices", or "you cannot use this on platforms with poor support for shared libraries such as windows or mac os" (by which I mean that these platforms don't have real package managers to handle dependencies, and the end user has to either (1) install DLLs manually or (2) install "unshared shared libraries", i.e. one full instance of the library per program using it, which OSX calls an "app").

I am not a lawyer, but GPL2 seems to be free of these. We're not likely to pick anything much more permissive for now. Also, the Pijul and Darcs teams agree that we don't particularly enjoy discussions about licenses, especially when they're not based on factual arguments. Here are answers we've already given:

- If you think that "a new anarchistic jurisdiction not recognizing any copyright law will soon emerge, hence Pijul should be in the public domain", we don't agree. The movie Dunyayi Kurtaran Adam, also known as Turkish Star Wars, is available full-length on youtube, to remind everyone that copyright laws may be broken, but not totally useless. Therefore, your dream country may not "emerge" that soon.

- Or maybe you think "I'd like to make a living from selling a small wiki based on Pijul, leveraging not only your research ideas, but also the database backend you spent 6 months full-time writing, as well as you SSH library. Why would you not allow me to do that?". The answer is: because if your wiki is useful, we want to use it too, without having to pay! What sense of fairness is this?

First of all, from the FAQ:

> But maybe we’ve missed something, and the AGPL actually prevents some use of Pijul that we’ve not thought of, and that does not aim at centralizing the internet. If this is the case, please discuss your idea with us on the mailing list.

Second, I wonder how many companies really had to change the source code of git, subversion, mercurial etc. What somebody could do is build a web services around it. As far as a service interfaces pijul with a system() it won't have any licensing problems. Encapsulate it into some RPC wrapper for extra safety. You might have to distribute the wrapper but it won't make it much easier for the competitors. The bulk of the web service can still be closed source.

Third, GPL licenses are fair to the original developers and the end users (they get to see the code they use). I understand why other developers might like BSD style licenses and we could spend another 30 years arguing about the virtues and the flaws of the two approaches. I won't get into that but given their goal of decentralizing the Internet I think they picked the right license.

I may be wrong but I think some (most? all?) companies that are blacklisting agpl3 won't bother going into small print details, license alone is a no-go, no?

Only uneducated people think that merely using or deploying AGPL software is 'problematic' in any way. Please don't spread that unreasonable fear.

Since when does anybody ever check the license of compiled binary applications?

And there will be no PijulHub.

This might be deeper than you are looking for, but this is the theory it's based on, and even has diagrams. :)

https://arxiv.org/abs/1311.3903

Here is one concrete example compared to git I found digging around: https://tahoe-lafs.org/~zooko/badmerge/simple.html

https://twitter.com/acid2/status/811691084623527940 has some update

I've shared the link because that's an interesting project and I'm interested in what people have to say. I wasn't expecting to reach the front page to be honest.

Git (and mercurial, and a few others) are snapshot-based. That means that they think of the world as states, with changes between them.

Darcs, and pijul, are patch-based. That means that they think of the world as an ordering of patches. Patches aren't the same as commits: commit orderings, for example, are fixed, whereas patch orderings are computed. They can change when you e..g merge a "branch". Branching is similarly "simpler": a branch is just a collection of patches, not just a single commit with an implicit DAG attached to it.

I guess, you will see a lot more parallel branches with Pijul compared to git.

Assume you change file A, commit, then change file B, and commit. In git there is a dependency from the second to the first commit, because the state of the second is derived from the first one. However, the changes are unrelated because they are in different files. Pijul understands them as parallel unrelated changes (although with different time stamps).

(disclaimer: I infer that from using darcs many years ago. I never used Pijul)

> How does this compare to git?

Apart from the other answers that go into theories of patches vs. commits, I always found Darcs much more intuitive to actually use than Git. It has fewer commands that do more intuitive stuff. To record a patch, you do "record" instead of separate "add" and "commit" steps. To revert some changes you have not recorded and that you want to get rid of, you do "revert" instead of "checkout -- filename". The "diff" command works more intuitively than git's "diff", which you sometimes have to use as "diff --cached" due to its staging model.

Another thing is that every branch is a separate copy of the entire source tree in your file system. A drawback is that this can be viewed as wasteful, but the advantage is that it's much much easier to work in parallel branches at the same time since changing the branch is just doing "cd" instead of some boring dance of "stash" and "checkout". You also don't get problems due to files intended for one branch still lying around after a "checkout" to switch to another branch.

(I'm assuming that Pijul preserves all or at least most of these properties of Darcs. The docs aren't very exhaustive.)

That's a bit involved, but I believe that the intent is that Pijul is to Darcs as Git is to Monotone.

Math itself isn't necessarily intuitive in every case, but I think their point is this: if their system follows the simplest (i.e. most general) mathematical model, things will be more intuitive (i.e. more special cases == more difficult to reason about).

Let's look at example from math: integers and addition. Addition is pretty general -- there aren't, say, weird special cases when one operand is even, or the current date during calculation is Friday the 13th. Addition is associative and commutative, so I can evaluate a long summation in any order I want, or I could chunk up the calculation and have multiple computers evaluate parts thereof, all without any coordination/locking. It's easy to reason about, because the rules are so general, and generalization is what math is all about.

Now let's look at software: packaging. What are the semantics for package installation for your language/OS? If you install package A and then B, do you end up with the same result as you would by installing B and then A (i.e. is installation commutative)? Many (if not most) package managers can only support one installed version of a package at a time, and thus installation can not be commutative: installing a package will pull in dependencies that will influence package constraint resolution in subsequent installations, so order does matter. Now you have to be careful not to fuck that up when you set up your cluster's configuration management (or, hell, just get what you need installed on your laptop so you can work on a new assigned project). Now, if the package manager in question supported multiple installed versions of a given package (and had a way of "activating" only a subset of all packages for a given project/application), installation would be commutative, freeing you of the burden of installing things just the right way and in just the right order. This is how Nix (OS pkg manager) and the latest Cabal (Haskell pkg manager) work.

So, yes, coming up with a simple, consistent mathematical model for the semantics of your target system will definitely make things more intuitive. It's precisely because most developers are terrible at mathematical reasoning that so much software is so difficult to reason about -- there are tons of unnecessary special cases, when hidden inside all the tangled logic there's secretly a simple set of axioms and theorems that lend themselves to intuitive composition.

I think they're implying that the mathematical model creates a pattern of behaviour in the software that's intuitive.

For vim users, that's how vim keybindings work, for example (not everyone would agree vim is intuitive, hence I qualified the user-base). If you learn vim's keybindings, they're like axioms. You start to intuit the patterns like you would a language, eventually you don't think about how to do something, your fingers intuitively know.

Also supposing it were, git is also mathemagically intuitive when you view commits as isomorphic contours in source-code phase space (http://tartley.com/?p=1267) thus mathematical foundations are not enough to distinguish Pijul.

If you want to be good at math, you MUST gain an intuitive understanding of it.

Indeed, but if can accurately deduce what the behavior will be from a few relatively simple rules, then that is an excellent basis for forming an intuition.

What is "collaborative edition"? Does it mean the same thing as collaborative editing?

The case is simply that the authors probably have a different view of licensing, and wish that their code remains free software even when integrated in other products. It probably wouldn't help that much in the case of something like Github because Github uses their own version of git.

Depending on the outlook, AGPL is simply there to fix a loophole in the GPL, and rightly so.

The 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.

This 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.

Yes; "event sourcing" is a niche term for "maintaining a change log" which is quite literally the idea: keep patches, not states.

I used darcs for a while a few years back, it was ok. But definitely less polished than git.

Also the only vcs I've ever used where the repo managed to corrupt itself to the point I lost committed but unpushed changes

Darcs handles binaries, but not particularly well (ie, nothing quite next to the ease and brilliance of working with text documents). Binary merging is not well defined in general by any means, so binary is handled essentially at the entire file level. Because darcs patches need to [1] store the previous file state as well as the new/current one, patches in darcs with binary changes can get huge quickly.

Optimizations have been added to darcs over the years including some changes to something increasingly akin to git's hash storage for binary objects, but so far as I know, binary files that might change a lot over time are still mostly discouraged in darcs.

[1] To keep the patches reversible, for commutation.

It is heavily inspired by Darcs, and is based on an alternative "theory of patches" that reportedly has much better worst-case performance characteristics.

It is written in Rust, instead of Haskell, also contributing to better/more predictable performance.

The Darcs folks are very aware and supportive of it, and last I heard, Darcs might add support for the Pijul patch format.

This is an extremely exciting project.

(speaking as a long time Darcs fan and passive onlooker who saw the Pijul presentation at rustconf)

Not sure why this was downvoted, it is a legitimate question.

https://pijul.org/faq.html#did-you-solve-the-exponential-mer... answers it, at least partially. There may be a more comprehensive comparison, though.

It's supposedly faster, or, has a tolerable performance (I've nevere used Pijul, and never used darcs to the extent that it became slow).