2 ms·
I'm one of the authors, and we've done a lot of bibliography before engaging in such a big project. I'll talk only about the core principles behind version cont
by pmeunier 8y ago
I'm one of the authors, and we've done a lot of bibliography before engaging in such a big project. I'll talk only about the core principles behind version control, not about how things are actually implemented, or which options are the defaults in which tool.
Pijul is absolutely not how RCS or CVS worked. Instead, RCS and CVS worked more or less like SVN (remember the "CVS done right"?), and SVN itself is not too different from "Git without branches", or "Centralised Git", in the sense that these tools are snapshot-based (even though the actual implementations may store patches sometimes). This means that they see history as sequential, and use algorithms to merge when necessary. One could actually very well simulate a large part of Git branches and merges using multiple SVN servers, even though that would obviously be quite cumbersome to implement and use in any concrete situation.
The only version control system one can clearly relate Pijul to is Darcs, using the idea that patch commutation is the main thing people care about. Unfortunately, Darcs has important complexity problems when dealing with conflicts, and Pijul solves these problems.
That said, short-lived branches ("feature branches") in Git mostly try to simulate commutation, i.e. independent development mergeable later, hopefully in any order (since they were written independently).
- vnorilo 8y agoKudos on your work. I'm looking forward to trying pijul - I used darcs in the past and I miss some of its capabilities in the current git monoculture. Please ignore the negativity if you can - it's not like anyone was taking git away from people by suggesting that they might try a new thing.
- gumby 8y agoThanks for your response. I do think the archeological part of my brain was very confused/damaged; I think it was SCCS that kept the original document and applied patches as opposed to RCS which applied the "innovation" of maintaining the latests with deltas to go backwards. Luckily I haven't used any of those old systems in decades. IIRC BitKeeper followed the SCCS model. In any case good luck with Pijul; I do feel git has become a bit of a monoculture. In your discussion of model you mention binary blocks but don't otherwise mention binary files. Two major "shortcomings" of git (in quotes because they are explicit design decisions) are the lack of binary file support and the lack of very large file support. It's possible, but ugly. This means game developers (in particular) are typically unable to use git and are primarily stuck on Perforce, which is sort of like perpetually scratching yourself with a fork made of salt. The patch model might be a win here, especially if you could plug in format-specific "differs"