Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pijul – A free and open source distributed version control system

pijul.org

Post reply on HN
Print view View original

111–120 of 180 posts

Re: Pijul – A free and open source distributed version control system

#111

Post by BuuQu9hu »

mynewtb wrote: post #24
zellyn wrote: post #10

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.

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

I used to be at Google; AGPL was banned there. I hear that it is banned at many other large/huge shops.

I run a tiny business. AGPL is banned there too.

It isn't an "unreasonable fear". It is a reasonable decision based on mitigation of risk. AGPL is a risky license for end users; it goes too far beyond the Four Freedoms.

Re: Pijul – A free and open source distributed version control system

#112

Post by RaleyField »

dbmikus wrote: post #102
frant-hartm wrote: post #79

Earlier quoted context omitted.

> 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?

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…

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

Re: Pijul – A free and open source distributed version control system

#113

Post by atombender »

falsedan wrote: post #71
lvh wrote: post #60

Earlier quoted context omitted.

In darcs or pijul there is no DAG; there is only a collection of patches. The ordering between them is implicit, computed on demand, and can change as a consequence of merges.

It sounds as this is mostly an internal difference. Certainly, the mental model you described can be used on git reasonably well, from the user's point of view, and they won't get steered too far off course with it.

There are definitely many implications for users.

One thing you'll notice very quickly with Darcs (and presumably Pijul) is that the system always manages dependencies between patches. If you try to cherry-pick a single patch from a branch, you will get that patch and all the patches it depends on; you don't get the full linear history, you only get a subset.

In other words, you get the intuitive feeling that you're operating not on a log, but on a graph. Pulling one thread necessarily pulls other threads, and the whole graph rearranges itself to accomodate your changes. This has its downsides compared to the strictly-linear snapshot model, but the upside for most users is incredible. You can just commit and merge, and the system handles ordering for you.

Git was a major step down, UX-wise, when we switched from Darcs back in 2008, and it's still less user-friendly today. (It was also a major step up in some ways: Darcs, at the time, had a huge performance edge case where conflicts where sometimes effectively unresolvable because they took too much time to compute.)

Re: Pijul – A free and open source distributed version control system

#114

Post by m-j-fox »

zellyn wrote: post #10

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.

And there will be no PijulHub.

Re: Pijul – A free and open source distributed version control system

#115

Post by dbmikus »

RaleyField wrote: post #112
dbmikus wrote: post #102

Earlier quoted context omitted.

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…

> 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 appl…

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

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

Re: Pijul – A free and open source distributed version control system

#116

Post by Nullabillity »

frant-hartm wrote: post #79
scotu wrote: post #17

Earlier quoted context omitted.

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…

> 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?

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

Mission accomplished?

Re: Pijul – A free and open source distributed version control system

#117

Post by qznc »

kibwen wrote: post #42
fadzlan wrote: post #33

Earlier quoted context omitted.

Honest question, although on a bit different topic I guess. Does AGPL prevents some company creating Github like services for Pijul?

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

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!

Re: Pijul – A free and open source distributed version control system

#118

Post by jefurii »

cstrahan wrote: post #37
mhd wrote: post #26

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

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 curren…

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

Have you ever developed software outside of academia? Special cases arise when your perfect mathematically structured snowflake is put in the hands of actual users who want to do actual work with it.

A buddy of mine who did work with JPL has told me that NASA uses a decades-old FORTRAN app to calculate orbits. When I asked him why they didn't port it to a more modern language he said it was because the system has so many special cases and fudges that would take forever and the new system might not be able to replicate the features of the old one.

Of course having a logical basic architecture (example, a structure that encodes special cases as configuration) can make it easier to maintain as a project matures.

Re: Pijul – A free and open source distributed version control system

#119

Post by st3v3r »

frant-hartm wrote: post #79
scotu wrote: post #17

Earlier quoted context omitted.

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…

> 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?

You can't add proprietary bits to their system without contributing those bits back so everyone can have them. Boo hoo.

Re: Pijul – A free and open source distributed version control system

#120

Post by aseipp »

erichocean wrote: post #110
aseipp wrote: post #85

Earlier quoted context omitted.

It's not quite the same. Here is a very short video on a project called "Camp" that stalled out, nearly a decade ago. I think it very nicely explains how the user interface differs: https://www.youtube.com/watch?v=iOGmwA5yBn0 The most important thing is that because there is no DAG, when you say "Darcs, pull this patch for me", like saying `git cherry-pick ABCDEF` -- the dependencies are automatically computed and pu…

> If there's a bugfix, I say "Get me that bugfix patch". [..] It always just works. > Darcs almost always gets merges correct, or it fails to do the merge at all. One of these is not like the other, which IMO is the problem with "magical" merging systems. Great when they work, f*cking hell nightmare when they don't. I'd rather have something like git that works in normal usage all the time, and when it fails, is easy…

FWIW, this is traditionally quite possible with Darcs. I sort of misformulated in my original post; it's not like it just gives up and you're at square one. The workflow IIRC was basically the same as Git: it'll throw its hands up and you make a new commit to fix everything. So that isn't really a problem or any different. Note that Darcs 1 did have the exponential merge case on top of this, however, which was pretty unfortunate (and really a byproduct of the design of the change format, among other things).

In all honesty, given years of experience with Git, and fondly using Darcs as my first version control system: I still think merges are absolutely the one thing it beats Git at, hands down. When it works and it does its job, it always is correct. When it doesn't, you can bail it out. Not much different, but the "always is correct" and dependencies-being-implicit is what makes it good. Darcs could have saved me at least dozens of hours of hair pulling when doing STABLE merges I estimate... Git's still good. I wish it could do that, though...

Your note about git is interesting. In fact, Git is, in at least some cases, more magical than other VCSs in the merge department. You might just not be aware of it due to being so familiar. When I say "Darcs always gets the merge correct", I don't just mean it literally finishes with exit code 0, but also that the semantic model is, in some sense, more 'correct' or 'intuitive':

http://r6.ca/blog/20110416T204742Z.html

Darcs (and others) always get this 'merge associativity' case correct, where 'Base+A+B' where (+) is merge is associative (so it doesn't matter how you 'bundle' the changes or whatever). That means you have less edges to worry about. And to be fair, I don't think there's anything inherent about Git where this particular case can't be fixed. It's just a good example of why people are trying projects like Pijul/Darcs at all, so these things can be formalized and understood. The theory of patches is actually rather rich and helps formalize a lot of these notions of what a "merge" really is in an algebraic sense, how patches relate to one another, etc.

Post reply on HN