
Pijul – A free and open source distributed version control system - dgellow
https://pijul.org/
======
zellyn
Sadly, I'm afraid the AGPL license is going to make this untouchable to
businesses… :-(

[Edit] Interestingly, they cover that. I suppose if you're just running Pijul
rather than integrating with its code, it might be safe to use in a corporate
environment. Still, it's likely to be offputting.

~~~
scotu
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)

~~~
frant-hartm
> offer it as a sevice for money

Yes, you can, but if you add something - like issue tracking, user/access
management etc.. around that then you need to publish that under AGPL as
well..

It means it will never be part of something like github, bitbucket or AWS
CodeCommit.

And then there are plugins to CIs (checkout from repository ...) - would those
be affected?

~~~
dbmikus
Correct me if I'm wrong, but this only means that if you modify the code or
directly incorporate the code library into your own, you must distribute your
work.

If you are just calling the service through it's API (either CLI or through
the programming language interface), then you don't need to distribute
anything.

This just protects against people taking open source code GPL, modifying it
for themselves, using it in backend services, and then never distributing
their modifications.

~~~
RaleyField
> If you are just calling the service through it's API

That's contestable afaik.

> through the programming language interface

i.e. dynamically linking which is usually understood to be prohibited unless
linking code has a compatible license.

> either CLI

Here's the problem - you can take any GPL library, make small CLI or REST
adapter for it and license it GPL as well, then use that adapter from your
proprietary application - is that still allowed? Because if it is then GPL
can't ever be enforced and if it isn't you can't call CLI APIs even if
original libraries themselves provide it.

~~~
dbmikus
I was reading this[0], but didn't scroll down through the comments. It appears
you are correct.

However, I think if you just installed Pijul on a server and then called it
through your operating system interface, then you _might_ be fine. You might
need to make it so the interface to Pijul is generic and could swap out with
other VC systems.

I still might also be wrong about this. I'm not a lawyer and the comments in
[0] are on both sides of the argument.

[0]
[http://softwareengineering.stackexchange.com/questions/10788...](http://softwareengineering.stackexchange.com/questions/107883/agpl-
what-you-can-do-and-what-you-cant)

EDIT: edited to express less certainty over my interpretation of the license

~~~
RaleyField
> then called it through your operating system interface, then you _might_ be
> fine

Might, exactly. Depending on various courts accepting there is a loophole in
GPL, and my layman understanding is that there isn't. Skimming GPLv2 I don't
see them differentiating in derivative works between those that use compile
time linking and those that use mechanisms like CLI. I'm weary of bringing
after the fact constructs to justify something that GPL doesn't talk about.
And after all how is CLI that much more different than dynamic linking - CLI
is merely an interface that is subjectively a bit more friendly in certain
situations but this imo shouldn't a have a bearing in legal discussions.

------
aratno
Would love to see more explanation (with diagrams) of their patching model.
Right now I'm not convinced it has any intuitive advantage.

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

~~~
krupan
For anyone following along still, I just tried the bad merge example that
vesinisia linked to with both git and mercurial. Git does indeed do the wrong
thing as illustrated on that web page. Mercurial gets it right.

UPDATE: both git and mercurial get the concrete version wrong ([https://tahoe-
lafs.org/~zooko/badmerge/concrete-good-semanti...](https://tahoe-
lafs.org/~zooko/badmerge/concrete-good-semantics.html))

------
donpdonp
Is there any new status on this project?

The last blog post from 2017-Jan-10 says "I’m pleased to announce that we are
starting to test the first usable version of Pijul.We are not quite ready to
release.."

I was hoping that getting to the front page meant pijul had done a release but
I see nothing to that effect.

~~~
ocharles
[https://twitter.com/acid2/status/811691084623527940](https://twitter.com/acid2/status/811691084623527940)
has some update

------
gozzoo
How does this compare to git?

~~~
lvh
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.

~~~
krupan
This distinction between commits and patches (I've been following git, hg, and
darcs for over a decade) is one I've never quite understood. A patch says,
take this original line of code found here and change it into this new line of
code. A commit is just a patch that records when in the history you can be
sure to find that original line of code. If you take an arbitrary patch and
apply it to an arbitrary set of code you might not even be able to find that
original line of code. How do darcs and/or pijul solve that problem? Git and
mercurial have tools like rebase and cherry pick that allow you to rearrange
commits and they can even use three way merge algorithms (because of the DAG)
to help recompute the patches for when that original line of code isn't quite
what the patch specifies anymore. How are darcs and/or pijul different in that
regard?

~~~
jordigh
A commit is not a patch. A commit is just often represented as a patch (i.e. a
diff), but in general neither git nor hg even save a commit as a patch, except
as a minor, optional, and opaque optimisation. What they really save is the
entire state of your repo at a particular time, with the hash(es) of the state
of the repo just before this one. In the case of git, it saves a tree of
hashes that refer to all of the blobs (files) at the current commit. In the
case of Mercurial, it saves a manifest of hashes that point to files
represented in revlogs. Whenever both git and hg show you a commit as a diff,
this involves a computation. They are not merely showing you diffs that they
have pre-computed and stored.

Bitkeeper does have a weave data structure that more closely resembles
patches. It's an encoded set of instructions for transforming one file from
one state into another:

[https://www.bitkeeper.org/src-
notes/SCCSWEAVE.html](https://www.bitkeeper.org/src-notes/SCCSWEAVE.html)

This data structure has a big advantage when computing annotations (blames):
it's much faster than Mercurial's revlog (which in turn is faster than git's
blob-tree-ref structure).

~~~
halomru
All that sounds like differences in the intr internal model. From everything I
have understood it wor would be possible to reimplement git to store only
patches, their position in the commit tree and the commit hash, and have it
behave exactly like the git reference implementation.

Is the difference between patches and git commits in a DAG really only a
difference in internal representations or is there a user-facing difference?

~~~
jordigh
Speed is about the only user-facing difference. But the big user-facing
difference is that commits are glued to their parents. They really are glued;
the merges and potential conflicts involved with rebasing and cherry-picking
are a consequence of trying to undo this glue.

Darcs' and pijuls' patches aren't glued, they only either commute or do not,
and the conflict resolution mechanisms for non-commutative patches are
different.

~~~
krupan
What does commute mean in this context? I'm getting the impression that it
means that the original line of code that the patch references and is going to
change is where the patch expects it to be.

~~~
jordigh
It's probably best to get this from the source:

[https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...](https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory#Commutation)

------
mhd
"Because Pijul is based on a mathematical model of collaborative edition, its
behavior matches intution, every time."

That's not how math and/or intuition works.

~~~
cstrahan
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.

~~~
OJFord
I think you showed the opposite point - you've argued commutativity is
intuitive, but certainly non-commutativity can be part of a mathematical
model.

~~~
cstrahan
A simpler explanation to that of my sibling post -- your point is akin to this
fallacy:

Susan: My brother plays such great music with his violin!

Bob: Actually, I think you're arguing the opposite point -- a violin has
strings that can be mishandled such that they cause annoying screechy sounds,
so surely he's capable of producing a cacophony of screechy sounds. Not so
enjoyable.

Susan: Okay... but he's a _good musician_ , so though he _could_ fuck up a
performance if he wanted to, he _doesn 't_ \-- he plays to the best of his
abilities.

If a math model claims that something isn't commutative, it's either as
simple/general as it can be, _or the creators of that model are bad at math_
(they left commutativity on the table due to bad axioms, or their theorem that
the given operation was not commutative was _wrong_ ).

~~~
OJFord
I have no idea where we're going with this.

You're original argument was that mathematics can model things that we might
arrive at intuitively, without looking at the model - such as assuming
commutativity in package manager installation order - correct?

I'm simply saying that mathematics can also describe things which are
surprising; counter-intuitive even, so I agree with 'higher' comments in that
being:

> _based on a mathematical model of collaborative edition_

is not sufficient for having that:

> _behavior matches intution, [sic] every time_

It just doesn't follow. Not least because one man's intuition differs from
another's.

~~~
cstrahan
Emphasis mine:

> You're original argument was that mathematics can model things that we might
> arrive at intuitively, _without looking at the model_ \- such as assuming
> commutativity in package manager installation order - correct?

No, certainly not -- the right choice of model is key (a trivial example: one
system for strings would be one in which there _wasn 't_ an identity element
(that is, the empty string), thus making strings non-monoidal; that would
complicate matters like concatenating a list of nullable/optional strings).
I'm not claiming that to be the case, nor do I think the Pijul authors are
claiming that. I think we both would say that there _exists_ a model of any
given domain that is the most suitable for for that domain ( _not_ that just
_any_ given model will suffice), and that it's math that helps you discover
it. I read that blurb on the site as (the slightly tautological) "because we
chose a _good_ mathematical model, you can expect that the entities and
operations on those entities can be composed as advertised, rather than
_unintuitively_ yielding unexpected results (bugs) or unnecessarily
prohibiting some composition of operations that is clearly logically be sound
(which is also unintuitive -- why the special cases, when these things
_should_ compose?)".

> I'm simply saying that mathematics can also describe things which are
> surprising; counter-intuitive even [...]

Sure. An example: non-commutativity in in package managers that only support
one version of a given package to be installed. As someone who uses more
flexible package managers, I'm often surprised when I'm using another package
manager and discover its operations aren't commutative (which inevitably is
due to, as I discover shortly thereafter, that it only supports installing one
version of a given package at a time). That model requires extra brainpower to
think through how I'm going to coax the package manager into installing what I
need without conflicts (of course, after I've jumped through hoops to
uninstall all the bad versions first). A mathematical model can be given for
these systems, and they surely are convoluted and _bad_ \-- but just because
we can come up with convoluted messes in math doesn't make math any more
antithetical to intuition, that's just user error.

In this case, the package manager developers never set out to codify the
formal semantics for these systems -- they just grew organically from initial
needs. If they had started with an explicit mathematical model and iterated on
that model, and assuming they had any math proficiency here, they would have
done the convenient thing and allowed multiple package versions, and would
consequently have commutative package installation (and I wouldn't have a
notepad full of notes on how I need to carefully serialize my installs so that
I don't get conflicts).

>> based on a mathematical model of collaborative edition

>is not sufficient for having that:

>> behavior matches intution, [sic] every time

Sure, not sufficient, but _necessary_ (unless you count the possibility of
just randomly stumbling into the best model). It's also necessary that you
chose the best model for what you want (where "what you want" is surely a
subjective matter, but efficacy can often be measured objectively in terms of,
say, how much time is spent doing the same thing in two systems (assuming a
similar level of mastery in both systems)).

> It just doesn't follow. Not least because one man's intuition differs from
> another's.

Ok, intuition is a subjective measurement, but I think there's still value in
trying to find a pattern in what people generally find intuitive, rather than
dismiss the topic entirely. I'm suggesting, anecdotally, that fewer arbitrary
edge-cases is easier for human brains to deal with, and I think few would
argue with that. Math is, to a large extent, the process of shaking out those
generalizations from a bunch of concrete observations, so I would surely trust
a system where someone could point out their logic in the construction
thereof, over some system where the authors shrug and say "I dunno, that's
just the way I built it." (which is most software I've come across). Seeing
that note on the Pijul site inspires confidence: even if their model isn't
maximally generalized (yet), I know that it's something they have an
appreciation for, so I can come in and propose improvements (the same cannot
be said for projects where the leadership can't appreciate such proposals due
to a lack of the mental/mathematical framework necessary to conceive of the
positive consequences thereof).

Given my heuristic for intuition ("as few edge-cases as possible"), it would
seem that math would be _requisite_ here. Do you disagree with that, or do you
perhaps interpret that blurb from the Pijul site as claiming that (any
unqualified) application of math is _sufficient_ for developing an intuitive
system?

------
mirekrusin
Is there any sound reason to use AGPL3 license in this case? Is it to avoid
private, non-public modifications by some future pijulhub.com? Something,
somewhere feels irrational in my head, especially when I think about popular
projects like SQLite which seem to be doing just fine without the whole
license thing.

~~~
ue_
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.

------
gpm
Hopefully they release "workable pijul" soon (they said on January 10th that
they were almost there) [0], they haven't updated the source in the darcs
repository June 1st.

[0] [https://pijul.org/2017/01/10/first-working-
pijul.html](https://pijul.org/2017/01/10/first-working-pijul.html)

------
rhabarba
Last time I checked, the Darcs project had mostly fixed the performance
issues. Shouldn't it be better to concentrate and unite their efforts?

~~~
lvh
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.

------
kabes
Do I understand it correctly if I say this is like the event-sourcing model
applied to version control?

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

------
giancarlostoro
Looks like this is inspired by Darcs but was originally an attempt to improve
it for those curious about it as I was. It is written in Rust which gives it
all of the benefits (and weaknesses(?)) of Rust.

------
maxpert
Is anyone using Darcs or Pijul at work?

~~~
stestagg
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

------
alkonaut
Says it's only text yet - is there a plan for binary? Does darcs work well
with binary?

~~~
WorldMaker
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.

------
tmsldd
$ alias pjl 'pijul'

... much better now..

------
angvp
oh what a great idea, let's build pijulhub!

------
adekok
How does this compare to darcs?

[http://darcs.net/](http://darcs.net/)

Edit: they have some minor text on how it's better, but a more detailed
description would be appreciated.

~~~
tupshin
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)

~~~
agumonkey
I find it very uplifting to see both team exchanging so nicely.

Feels like good research and progress.

------
X86BSD
How is this different from, my personal favorite, Fossil. [http://fossil-
scm.org/index.html/doc/trunk/www/index.wiki](http://fossil-
scm.org/index.html/doc/trunk/www/index.wiki)

~~~
j_s
Do you have a moment to explain what makes Fossil your favorite?

As far as I know, the only unique aspect of Fossil is "Integrated Bug
Tracking, Wiki, and Technotes".

~~~
X86BSD
Those are certainly very nice features to have. For me the syntax and ease of
use is what I like. Although that is all subjective to each person of course.
Plus the author is a great guy. No ego at all. Plus the license is more
appealing to me.

------
Kiro
Why don't I ever see CC on OSS? Always these complicated licenses.

~~~
l2dy
[https://creativecommons.org/faq/#can-i-apply-a-creative-
comm...](https://creativecommons.org/faq/#can-i-apply-a-creative-commons-
license-to-software)

> Unlike software-specific licenses, CC licenses do not contain specific terms
> about the distribution of source code, which is often important to ensuring
> the free reuse and modifiability of software. Many software licenses also
> address patent rights, which are important to software but may not be
> applicable to other copyrightable works. Additionally, our licenses are
> currently not compatible with the major software licenses, so it would be
> difficult to integrate CC-licensed work with other free software. Existing
> software licenses were designed specifically for use with software and offer
> a similar set of rights to the Creative Commons licenses.

------
baq
AGPL3 sounds like a death sentence given recent RethinkDB struggles, which is
just sad, because the project looks very cool.

~~~
3825
Any sources behind the claim that agpl is behind the lack of success for
rethinkdb?

I am very bullish about agpl. As far as I understand, the choice of agpl has
no effect on your code which you put in a repository. Is that not the case?

~~~
fadzlan
Honest question, although on a bit different topic I guess.

Does AGPL prevents some company creating Github like services for Pijul?

~~~
kibwen
It does not prevent any company from creating a Pijulhub. However, if you make
modifications to Pijul or link it as a library into other code, that code must
be made open-source.

(And note that GitHub doesn't even use the original git written by Linus, they
wrote their own implementation, libgit2.)

~~~
qznc
Afaik libgit2 is a derivative of git.

Anyways, for Pijul to be successful, there must be something like PijulHub.
The bar is higher now. Thus, make it easy to build this hub!

~~~
kibwen
Being open-source doesn't make it any harder to build a centralized source
code hosting site, it just makes it harder to get VC funding. :P

