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

171–180 of 180 posts

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

#171

Post by luismbo »

atombender wrote: post #113
falsedan wrote: post #71

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.

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…

I miss Darcs too. One potential downside of making cherry-picks very easy is that abusing them can bite you: two patches might be independent in terms of conflicts but functionally dependent (e.g., code in patch A calls a function introduced by patch B).

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

#172

Post by WorldMaker »

falsedan wrote: post #168
WorldMaker wrote: post #147

Earlier quoted context omitted.

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

Obviously there are plenty of anecdotes on both sides, but I had to (try to) force a moratorium on git cherry-pick between long running branches at a previous job because merge problems became a huge sink of time. (This was after they'd already had the same problems in TFSVC and seemed adamant to recreate that problem in git.)

You seem to think its "fetch a branch", but I'm trying to tell you that the `darcs pull` experience is a lot more like doing `git fetch && git cherry-pick origin/TIP --interactive` every time than `git pull`, but with a much, much better merge experience than that implies.

I'm not trying to confuse different concepts, I'm trying to show that the hard concept in the git case was the easy concept in the darcs case.

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

#173

Post by st3v3r »

millstone wrote: post #158
st3v3r wrote: post #119

Earlier quoted context omitted.

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

This is the big conceit of copyleft licenses: that "derivative works" are exclusively "modified and extended versions of the program" to use the FSF's terminology, and not a small piece of a much larger system. It's easy to imagine wanting to add Pijul support to Tower, SourceTree, Gerrit, Phabricator, etc. - projects that all dwarf Pijul. But these projects will be unable or unwilling to risk doing so, because of th…

I'm sorry, but that's nothing but FUD. Tell me exactly why those projects would be unable to integrate.

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

#174

Post by mst »

tghw wrote: post #48
jdbernard wrote: post #38

Earlier quoted context omitted.

Git stores diffs, not snapshots. A commit is a changeset, literally a patch that you can export with `git diff`. Ordering of is layered on top of that and informs things like merges. Can you explain a little more what you mean?

Not sure why you're getting downvoted, you're describing git correctly. If anyone is questioning this, just play with `git rebase -i [some old changeset id]` and you'll see that it's just an ordering of patches.

rebase turns the snapshots temporarily into a stack of patches, lets you play with them, then turns them back into snapshots.

In fact, this is why rebase is an out-of-band tool that has odd effects on shared history - specifically because it's inverting git's model into something more like pijul's, and therefore isn't really native-to-git.

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

#175

Post by WorldMaker »

alkonaut wrote: post #143

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

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.

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

#176

Post by Crespyl »

pmeunier wrote: post #163
halomru wrote: post #88

Earlier quoted context omitted.

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

Thanks for that link, that finally helped me understand the real benefit of the patch model, this quote in particular:

> The difference between what svn does and what darcs does here is, contrary to popular belief, not that darcs makes a better or luckier guess as to where the line from c1 should go, but that darcs uses information that svn does not use -- namely the information contained in b1 -- to learn that the location has moved and precisely to where it has moved.

Darcs/Pijul understand which lines a patch is interested in, and if those lines get moved around in another branch, the patch "follows" them to the right place, rather than just finding/applying the shortest possible diff.

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

#177

Post by pmontra »

millstone wrote: post #159
bachmeier wrote: post #154

Earlier quoted context omitted.

> I wonder how many companies really had to change the source code of git, subversion, mercurial etc. Even that overstates the matter. Companies could modify the code all they want as long as they don't distribute that code. That would impact Github competitors - maybe 10 or 20 companies in the entire US.

Facebook uses derivatives of PHP and mySQL today, because those are the technology choices Zuckerberg made in 2004. You hope you should be so lucky! Also, "distribute that code" can be interpreted very broadly. A contractor may access your internal HR system, and now you have to share it with them. A factory line worker may be entitled to the source controlling the robot fixture. A airline passenger may use the in-fl…

If the HR, the robot and the entertainment systems are AGPL licensed chances are that their source is already on github.

Spot on for PHP and MySQL. PHP has its own license (kind of BSD?) and MySQL is GPL2 or commercial. I bet Facebook could buy the rights of any AGPL product, unless the owner is really firm about principles.

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

#178

Post by krupan »

vesinisa wrote: post #128
aratno wrote: post #29

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

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

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

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

#179

Post by larkost »

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.

Apple's lawyers are definitely educated, and they have put their foot down within Apple. And Apple is not the only large organization where exactly that has happened. You may well disagree with them, but they are the ones far more educated in the law, and they are concerned by it, so there is probably something to it.

The speculation I have heard is that the terms "deploy" and "link" are both ill-defined and have not gotten proper testing in the courts. So there is no case-law saying that pushing your changed binaries to 1,000 internal sites (or even better: partially owned subsidiaries) does not invoke the clause. Or what does "linking" mean in the context of a database driver? What happens if a well-meaning employee loans out a modified binary to a customer to see if it fixes their problem? All of that makes lawyers nervous, and what makes one lawyer nervous has the potential of making other lawyers rich at their companies expense.

Just because you read something and come to a conclusion does not mean that people who come to other conclusions are "uneducated".

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

#180

Post by gue5t »

kabes wrote: post #87

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

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