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

Commits are shapshots, not diffs

github.blog

Post reply on HN
Print view View original

151–154 of 154 posts

Re: Commits are shapshots, not diffs

#151

Post by gnufx »

pmeunier wrote: post #149
gnufx wrote: post #145

Earlier quoted context omitted.

I'd still like to know if you're claiming Darcs 3 (which may or may not be at a similar stage of development) still has that issue (which I don't remember biting me). I've no particular axe to grind as a Darcs user, as long as I have a nice patch-based system.

I don't think Darcs 3 was even started. Darcs 2 recently solved the exponential merge, but it is now quadratic (which is still exponentially slower than Pijul instead of double-exponentially). I've also been really happy with Darcs, expect for two things: - Conflicts are not handled very well, as if they were not properly stored internally. `darcs revert` on a conflict doesn't always do what I expect. - The fact that…

I should have explicitly said the version 3 theory, which has an imlpementation in Darcs 2.16. I've never seen worst case quadratic complexity, like quicksort's, labelled exponential before, which seems misleading. I think there's more to practical scalability than worst-case asymptotic complexity, even if guaranteed linear is likely a good start; have the two been compared for Linux or GCC, for instance? I'd be happy to use the best combination of speed and features/usability.

I just set up Trac for Darcs hosting -- though it has some tension with the Subversion model -- exporting to git for people who want the pain. I'd investigate Sourcehut integration if I had the time.

Re: Commits are shapshots, not diffs

#152

Post by kelnos »

em-bee wrote: post #115
kelnos wrote: post #109

Earlier quoted context omitted.

I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeepe…

This is where Torvalds should have gotten his big honking "I told you so", but I expect he took the wrong lesson from it which lesson did he take and what should he have learned instead?

What I think he should have learned: betting the workflow of your open source project on a closed source solution is going to come back to bite you, and you shouldn't do that in the first place.

What he probably learned: I'm badass enough to clone a proprietary tool in a matter of weeks if my decisions end up being bad.

Which I guess is fine for him, but likely not most people.

Re: Commits are shapshots, not diffs

#153

Post by kelnos »

Pet_Ant wrote: post #111
kelnos wrote: post #109

Earlier quoted context omitted.

I read a lot of the mailing list threads back when all this was going on, and I don't recall feeling any particular sympathy toward McVoy at all. The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeepe…

> The fundamental issue I saw was that McVoy decided to foist what I consider an unconscionable license agreement upon his unpaid open source users: users were prohibited from working on another version control system without having their license to use the read-only BitKeeper client revoked. (And reverse engineering BK's protocol was also forbidden.) From the starting line I already thought he was slimy for that. I'…

I get that you might have no problem with that, but personally I find that kind of arrangement unethical, and I would never agree to that sort of license.

Also note that I believe the "free for open source users" version of the BK client was a read-only client that only allowed pulling code. So it's not like McVoy was giving his whole product away for free, out of the generosity of his heart.

> ...and all I ask is not to try to take more from me?

Reverse engineering is a neutral activity. There's no "taking" going on.

> I always though that Tridge was ungrateful in the situation.

Ungrateful that he was forced to use a crippled, proprietary tool to interface with the development process of a project he's involved in? A tool that expressly disallows him from doing anything to make that situation better? That's rubbish.

Post reply on HN