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

161–170 of 180 posts

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

#161

Post by scotu »

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?

I literally wrote that you need to publish that under AGPL any extensions, so you didn't really blew my mind there...

It definitely be part of something like Gitlab (or github, bitbucket or AWS CodeCommit), you just have to model your business around the fact that the software is available to everybody. You know, like wordpress (sure, they are GPL so they can have some proprietary components but the practical implication is that you CAN create your own, for pay, wordpress.com service).

Plugins can be a different story. Does the software have a rest interface? then use that, no license virality. If it doesn't, you release them AGPL

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

#162

Post by tom_mellior »

millstone wrote: post #157
chriswarbo wrote: post #148

Earlier quoted context omitted.

> if you checked in AGPL code This sounds like taking some of Pijul's source code and putting it inside another project. That would certainly have business implications, which justifies ninjas. It's possible to use AGPL as a business strategy (I worked at a company whose main product used CPAL[1] which has a similar network-use clause); but such decisions should not be made via VCS commit. Of course, if the choice of…

If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Those internal barriers usually incur a cost that outweighs whatever benefit the code provides, relative to unencumbered alternatives. If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your…

> If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects.

Yes, but this has nothing in particular to do with the AGPL and everything to do with copyright laws. There is no licence except public domain/CC-0 that allows BigCorp to incorporate other people's code without any obligations whatsoever (attribution, at least). Copyright laws forbid such incorporation by default.

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

#163

Post by pmeunier »

halomru wrote: post #88
jordigh wrote: post #69

Earlier quoted context omitted.

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

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…

It would be certainly be possible to reimplement git using only patches, showing that Pijul cannot be worse than git.

However, it would not be possible to implement a patch-based system (Pijul/darcs) based on git.

- One example is cherry-picking: in git, when you are on some branch A, and cherry-pick from another branch B, after the cherry-picking is done, if you try to cherry-pick from B again, you'll get conflicts. In Pijul and darcs, that comes for free.

- Another example is merge: merge between commits is provably wrong (https://tahoe-lafs.org/~zooko/badmerge/simple.html). With patches, this cannot happen.

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

#164

Post by tom_mellior »

gozzoo wrote: post #27

How does this compare to git?

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

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

#165

Post by pmeunier »

krupan wrote: post #54
lvh wrote: post #35

Earlier quoted context omitted.

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

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…

A commit stores information about the state of the whole repository (in hashes). A patch is stateless, just describing what operations you do on the repository.

One confusing thing for git users is, git represents a number of commits (but not all types of commits) as patches.

Two differences:

- Cherry picking is possible, but when you cherry pick twice from the same branch, you get conflicts with commits, because cherry-picking change their identity. With patches, this works just as expected.

- Merging can be made associative with patches, not with commits. Concretely, in git, if Alice and Bob add lines to a file, even when there are no conflicts, Alice's new lines can be merged in the middle of parts added by Bob, even though she's never seen these parts. Even worse, there is no way to tell when this happens to you (git doesn't say). "Associativity" is the mathematical property that this never happens.

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

#166

Post by pmeunier »

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…

If you try to analyse merge systems mathematically, git's merge system is the "magical" one. It is just a heuristic algorithm, with no solid property you can rely on.

In contrast, Darcs and Pijul's merge are associative, and Pijul's merge is commutative. Even if you don't like maths, this means that they will always behave deterministically. This also means you can use them in scripts, although darcs might sometimes have performance problems (pretty bad ones, actually).

In git, you can get the following: https://tahoe-lafs.org/~zooko/badmerge/simple.html

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

#167

Post by falsedan »

lvh wrote: post #145
falsedan wrote: post #141

Earlier quoted context omitted.

I still don't get it: pulls don't merge DAGs, they add objects and move refs (and maybe merge); every time darcs fans say 'patch' (as a collection of related changes) I think, 'oh like a branch?' This sounds less and less like a tools/implementation thing and more like the default recommended/enforced workflow thing.

How does the fetch part know which objects to grab? (Answer: because it cared about the DAG first.)

That's begging the question: git-upload-pack takes a ref and a commit ID, and returns a pack of objects to the requester to do as they like. I wouldn't call it a merge, but a set of operational transformation actions to be added to the requester's repo. It may not even examine the DAG at all, since it's possible to save those packs as 'bundles'!

My point is, if you focus on the implementation differences, my understanding won't increase because we don't have the same mental model of how git works under the hood.

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

#168

Post by falsedan »

WorldMaker wrote: post #147
falsedan wrote: post #141

Earlier quoted context omitted.

I still don't get it: pulls don't merge DAGs, they add objects and move refs (and maybe merge); every time darcs fans say 'patch' (as a collection of related changes) I think, 'oh like a branch?' This sounds less and less like a tools/implementation thing and more like the default recommended/enforced workflow thing.

To start by adding to your confusion: one of the early problems encountered in darcs git interaction actually was that sometimes a darcs patch acts more like a git branch than a git commit... It might help to compare the "identity" structures of git commits versus darcs/pijul patches. In a pseudo-C, you can see a git commit as something like: struct commit { string author; string description; tree_id tree_snapshot; c…

  Down the line when you go to reintegrate/remerge the
  branches between the original branch and the cherry picked 
  branch, git doesn't see the same commit/change and its merge
  can (in my experience, will) see conflicts in the exact same
  change made in different contexts.
Finally I see some common ground: by tracking changes separately to commits, users won't see merge conflicts when the commits get moved.

Sadly, git also recognises this on the user's behalf, so likely your experience was due to some other delightful quirk of the git UI.

edit: I'd also recommend not calling trees 'tree snapshots', because that will confuse people familiar with trees. Same for 'cherry-picking a commit', since from your description darcs seems to use 'cherry-picking' to mean 'fetch a set of changes from someone else', which maps to 'fetch a branch' in git-land. 'git cherry-pick' means, 'copy a single change from one local branch to another', so has almost no overlap.

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

#169

Post by chriswarbo »

millstone wrote: post #157
chriswarbo wrote: post #148

Earlier quoted context omitted.

> if you checked in AGPL code This sounds like taking some of Pijul's source code and putting it inside another project. That would certainly have business implications, which justifies ninjas. It's possible to use AGPL as a business strategy (I worked at a company whose main product used CPAL[1] which has a similar network-use clause); but such decisions should not be made via VCS commit. Of course, if the choice of…

If a BigCorp is to use AGPL code, it needs to erect internal barriers (on code search, etc) to ensure that said code does not find its way into other projects. Those internal barriers usually incur a cost that outweighs whatever benefit the code provides, relative to unencumbered alternatives. If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your…

> If you say "we don't plan to patch the code, just use the binaries as-is" then you're asserting that the software today your needs forever into the future. That's a terribly foolish bet.

I agree; one of the many reasons I'm against proprietary software is that it forces users into this helpless situation.

I don't quite get the "internal barriers" idea; is it common for companies to mix together code from multiple projects, including ones they don't own, such that it's difficult to disentangle them? Regarding your example, why would copy/pasting code from an internal code search be treated any differently from, say, searchcode.com? A modicum of diligence is always required regarding ownership, licensing, appropriateness, trust, etc.

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

#170

Post by psquid »

WhitneyLand wrote: post #51
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.

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

Exactly so. It's not strictly correct modern English as far as I know, but it's quite a common slip amongst French speakers (from their names I would strongly suspect at least one of the core Pijul folks fits that category) for whom the native word is indeed "edition".
Post reply on HN