101–110 of 180 posts
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.
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?
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.
Earlier quoted context omitted.
Internally, git objects are snapshots -- the differences are computed on demand. That is a critical difference, because it has implications for how merging can work. For example: https://tahoe-lafs.org/~zooko/badmerge/simple.html Even when using git am or send-email or whatever, yes, you're sending a patch -- but the way to apply that patch is to turn it into a commit and then cherry pick or rebase or merge or manual…
So, I didn't believe you because my internal mental model of a git repo is a DAG of changesets. And indeed, that is a good way to think about it, because almost all of git's operations behave like this. Commit history is almost always presented to the user as a series of diffs. But, you are correct. Internally, git stores the full contents of files and computes the diffs on the fly. For others' benefit, if you want t…
merging, rebasing, committing... all operate on refs. You might think you're transplanting changes (and you are), but the inputs are refs, and the outputs are refs. As you mentioned, refs are unambiguously snapshots.
Earlier quoted context omitted.
I thought git stored diffs too. But I don't understand what difference it makes, isn't the commit storage format an implementation detail? If you want to get to B from A, then I can store B or store B-A. When I have B and want to show a diff, I can calculate B-A. When I have B-A and want to show a diff, it's a no-op. When I have B and want to work, it's a no-op, but when I have B-A and want to work, I have to populat…
Maybe lvh or one of the others who has more experience with darcs of Pijul will chime in. They've probably spent more time thinking about this. One difference is that by storing the patches only you can understand more clearly what the intended change was. When you store the whole file it is easy to compute the difference between A and B, but may be impossible to compute the correct differences between A, B, and C. B…
Last time I checked, the Darcs project had mostly fixed the performance issues. Shouldn't it be better to concentrate and unite their efforts?
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.
How does this compare to git?
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 differ…
In theory, the number of possible branches is much, much greater (arguably infinite) for git. Commits have their own metadata, so just amending creates a new commit. Patches are immutable, and there's no independent artifact like a commit that incorporates the current set of patches.
Furthermore, darcs (and I assume pijul) absolutely let you make multi-file patches.
Last time I checked, the Darcs project had mostly fixed the performance issues. Shouldn't it be better to concentrate and unite their efforts?
pijul changes the theory, and does so in a way specifically to avoid slow algorithms.
Earlier quoted context omitted.
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?
Honest question, although on a bit different topic I guess. Does AGPL prevents some company creating Github like services for Pijul?
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…
afaik this means any kind of linking (static or dynamic), using a jar or using a npm package or similar..
>through the programming language interface
which implies some version of the above
Earlier quoted context omitted.
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.
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…
> 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 to fix. YMMV.