8 ms·

Pijul version control system

104 points by luu 11y ago

jpgvm 11y ago
Couldn't easily work out how it compares to git/svn/mercurial/darcs/bazaar. A comparison to any one of those would do wonders for the landing page.
- karaokeyoga 11y ago
  Agree. Maybe the "Why a new version control system?" blurb from the FAQ.
- gecko 11y ago
  It presents the same conceptual UI as Darcs (it's patch-based, not snapshot-based), but provides the performance of Git and Mercurial. It does that by changing the internal storage of how patches work compared to Darcs. If you know Darcs, that's your entire sales pitch: Darcs, but now performant. For everyone else: In Git and Mercurial (and Bazaar, Monotone, Subversion, tla, Fossil, TFS2, and others I'm forgetting), the state is always represented conceptually as a snapshot of the current revision and a pointer to the snapshot of previous revision or revisions, so if you identify that you're at "snapshot 590", and I'm also at "snapshot 590", we're both at the same thing, and both have exactly the same history of how we got there. In a patch-based system, like Pijul or Darcs, that's not true. The state is instead represented by the set of applied patches. These usually have an implicit ordering, but you and I can theoretically have the same patches applied and have a different ordering. (We also can briefly have different resolutions to merge conflicts that result from that, and Darcs' historical inability to deal efficiently with you and me resolving conflicts differently is a major reason it doesn't scale well.) That sounds weird, but can have major benefits. For example, I can now sanely cherry-pick a bug fix from you regardless of the history of that bugfix--and, unlike in Git and Mercurial, Darcs/Pijul will know that the patch I cherry-picked from you is the exact same one that you have on your branch. No duplication, Cherry-Pick: messages, or merge collisions will result if I later pull in your whole branch (or vice-versa). You can also do things like have a patch that has all of your security settings, but always simply not push that when you push out to a public server. (N.B., giving this as an example, not best-practice.) If Pijul works, and can provide Darcs' model in an efficient way, it'd be really awesome. I'm not sure whether it'd be better than Mercurial or Git's model at scale, but it's been really hard to answer that question historically when Darcs itself didn't scale well. Pijul could change that.
  - jerf 11y ago
    "That sounds weird, but can have major benefits." I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. It never comes up in SVN or similarly klunky systems, because they're too incidentally complex to notice the underlying essential mismatch. Git and friends, to their credit, made the incidental complexity go away, but I think the essential complexity of their approach is still higher than it ought to be. I wish pijul all the best, because there is room for improvement here. And may I suggest to the pijul team that they really, really want a Pijul-hub as soon as they think they're even remotely ready.
    - gecko 11y ago
      I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. I actually agree. I advocated for DVCS-based workflows for a long time, but I think it speaks volumes that I "got" Darcs within about 20 minutes of first seeing it and playing with it, but I know for a fact that, somewhere in the Freenode archives, you can find me saying "The frak is Mercurial? The frak is Git? The frak is this?" as I tried to grok what on Earth they were doing--and this after having taught myself tla! That said, just because something is intuitive doesn't necessarily mean that something is best engineering discipline. I want a Darcs-like workflow to be the dominant one specifically because it's intuitive, but I'm very open to the fact that it might be a really, really crappy way to build a sane (forget performant) large code base. Or it may be exactly what we've always wanted. The simple fact is that I have no idea. This industry, for all the "science" in CS, has got to be the least results-based discipline I'm personally aware of. Pijul will at least permit anecdotal tests of how well patch-based systems scale as a workflow if it takes off, but I'm not holding my breath on someone doing a genuine A/B productivity/trade-off study.
skywhopper 11y ago
Sounds like it aims to be a (much) faster darcs. But between the name and the fact that they are trying to maintain two separate codebases (OCaml and Scala) that both do the same thing, I'm not super optimistic about its prospects.
- gecko 11y ago
  That should make you more optimistic! They want to make sure that the data format is well-specified from the very beginning, ensuring that there can be a third-party ecosystem that doesn't have the issue Git has right now where the only real definitive definition of Git's data formats is Git, yet people expect libgit2, JGit, etc. to work.
- placeybordeaux 11y ago
  If you are worried about two languages... >28 October 2015: Discovered Rust, a functional language that is not only type-safe and fast, but also has threads and binds easily to C on Linux and Windows. Looks like a good target.
anton_gogolev 11y ago
> ...snapshot-based systems can be extremely fast, but require an in-depth knowledge of their internals This is false, as demonstrated by Mercurial.
- testcross 11y ago
  Can you give more details or a link about this please?
  - gecko 11y ago
    I think he just means that, while many Git users may indeed be familiar with blobs, trees, commits, packs, refs, remote refs, and so on, most Mercurial users just know that they have changesets. Most Mercurial users do not know what filelogs are, how they work, what the manifest is, and so on. That said, I find the original claim, that users of snapshot systems have to know the internals, a bit idiotic. Subversion users definitely didn't, nor did most CVS users. Git seems to just be a very loud exception. Whether this is by necessity due to Git's UI, or whether it's simply that Git's data structures are more visible and discoverable, is a debate I'm not touching. (I'd note that there's a direct 1:1 correspondence for all core Git and Mercurial internal structures, so it's definitely not inherent in the snapshot model. There are even very nearly 1:1 analogs to older DVCSes, like BitKeeper and Monotone. Git users just tend to know more about the internals of their tooling.)
  - IshKebab 11y ago
    Probably not but he is right - all the git tutorials inevitably lead to explaining how git works internally. It is considered necessary knowledge for "grokking" git. Mercurial tutorials aren't like that. It is a lot simpler to use so Mercurial tutorials tend to just tell you how to use it and don't mention the internel implementation details.
- Grue3 11y ago
  I dunno, Mercurial Queues are pure black magic that only the most advanced dark wizards can possibly understand.
ebbv 11y ago
This seems like a classic case of novice developers thinking it's a great idea to re-invent the wheel. The page gives no compelling reason why I'd want to adopt this over the much more mature solutions out there. I say they are novice because they are maintaining two parallel codebases, which is a mistake no experienced developer would make.
- testcross 11y ago
  That's why there is only one implementation of git in the world. Oh, wait...
  - heinrich5991 11y ago
    They're not maintained by the same team though.
- boothead 11y ago
  Clearly rank amateurs to develop a working piece of software from category theory.
  - jdbernard 11y ago
    Experience in an academic discipline does not imply experience in software development. I don't know the authors, so I hesitate to judge, but starting with two code bases seems like a pretty rookie move to me, at least without a very compelling reason.
    - vezzy-fnord 11y ago
      Just look at those plebeians at Shen.
    - rejschaap 11y ago
      It might not be such a bad idea. If the main goal is to develop a specification or standard then it makes sense to have several implementations. The implementations can be used to flesh out and improve the specification. Also, from their website: Why rewrite it in Scala? The Scala implementation is not competing with the OCaml implementation, we do plan to maintain both in the future. Having several implementations of the core forced us to really think the formats through, and will allow others to write tools in the languages the like best, for their favorite platform (try to get and compile OCaml Pijul on Windows!).
dchest 11y ago
SHA-1 and 32-bit time for a new project in 2015?
- elcct 11y ago
  This happens if you lock yourself in a basement to code something for couple of years
- nsm 11y ago
  I understand the 32-bit time not being a good idea, but why is SHA-1 bad for a non-cryptographic application?
  - dchest 11y ago
    Because a hash function in version control system is a cryptographic application — it's important to be able to verify the integrity of repository.
    - nsm 11y ago
      Thanks. I am having trouble understanding how crypto would help (I did read [0]). The hash and the files are stored in the same repository. If an attacker edited a file, couldn't they update the hashes of that commit and everything related to it? [0] http://ericsink.com/vcbe/html/cryptographic_hashes.html http://ericsink.com/vcbe/html/cryptographic_hashes.html
      - __david__ 11y ago
        Yes, they could, but that's not exciting (that's really what `git --amend` and `git rebase` are, after all). What's interesting from an attacker point of view is changing the contents of the file (in a meaningful way) without changing the hash. That way anyone who pulls from you gets a different copy of the code, but they won't easily discover if since the hash is the same as the original copy. Think about what happens if you were to fork a copy of something on github and then rebase to edit one of the commits. If I pulled from your copy and the pulled from the official repo I'd get a merge (and probably some conflicts) because git identifies commits by their sha and uses that to decide what needs to be merged. But if you managed to change one of your commits without changing the sha, then I'd have a much harder time detecting it, since when I pulled from another repo later there would be no merge (even though things were actually different).
andersonmvd 11y ago
Is git that broken? To focus on replacing VCS, you should have a big reason for that I think. I'm just curious.
- krupan 11y ago
  git is an example of an amazing and powerful new VCS paradigm (distributed), but I sure hope we are not done making better and better tools, like, ever.
  - andersonmvd 11y ago
    I also hope we are not done making better and better tools, but to make something better, you need find some gap in current technology and fix it. That's what I am asking: which are the gaps fixed by this VCS? Or in simple terms, why should I switch?
    - mitchtbaum 11y ago
      I personally like very much how Golang and Rust have started to make low-level (mostly old and very important) applications more maintainable for a wider range of contributors (and readable for me); I see (coreutils)[0] as a great example. Also, I would throw Lua into that mix too, at least on some level. As it applies to this particular case, for instance, a repo object management function for lua-git, git implemented in Lua, (`Tree:checkout(path)`)[1] seems like something I could understand. I failed to find git's checkout function, even with a good bit of energy put into it. 0:https://github.com/uutils/coreutils https://github.com/uutils/coreutils 1:https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc971a8802f74a1921e0187e/lua/git/objects.lua#L84 https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc9...
    - WorldMaker 11y ago
      Git is a representation of history as a directed acyclic graph (DAG) of commits full of trees that are the state of the repository at the time of the commit. That DAG is strictly ordered (commits point to their parents and this is part of their identity so changing a commit parent makes a new incompatible commit). Darcs (which predates git, by the way) represents a repository as a loosely ordered set of patches (just the changes, not the full state at any given time). Darcs works to know how to rearrange patches in time to create new states. The difference/benefit to this approach is best illustrated with cherry-picking: in Darcs it is very easy to state that I want the patches my fellow developer created for modules X and Y, but I don't think he's done with module Z yet so I'm going to skip those. The patches can be interleaved and recorded in any order and Darcs will do all the hard work of figuring out how to grab just the ones I want, and do so without changing the physical identity of those patches (they are still the same patches my coworker developed). When this works, and it works 98% of the time without an issue, it is a wonderful magic. (Contrast this to git cherry-pick which builds new commits and is likely to have future merge issues with the commits it was built from, even those commits are somewhat "the same".) Pijul is an attempt at getting some of the same magic of a patch-oriented approach (and smarter patch merging) in a post-git world. Also, it's definitely early to talk about switching to Pijul.
zaphar 11y ago
Looks like a faster darcs. For anyone who has never used darcs a brief description is in order. Darcs is a revision control system based on something called "Patch Theory". That gives it some interesting properties. But for the user this translates into the possibly the clearest easiest to use interface of any DVCS out there bar none. It's merges are the least painless of them all in my experience. t's glaring flaw though is that it has historically been really slow as the repository grows in size. They've improved this since but it still can't compete with git and hg on speed. If it were faster though I'd use it in a heartbeat. Pijul looks to be a refinement of the darcs algorithms and thus much faster as a result. I'll definitely be watching them as they progress.
- maaku 11y ago
  You didn't really say what "patch theory" is. Can you describe or provide a link?
  - zaphar 11y ago
    https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
- emmelaich 11y ago
  > It's merges are the least painless Least painful - presumably :-) But I have heard that if things don't go well it's much harder to fix up.
- gnufx 11y ago
  It's been practical enough for me for a repo of this size for several years: $ darcs get http://arc.liv.ac.uk/repos/darcs/sge &>/dev/null $ cd sge $ darcs log --count 4851 $ darcs show files | wc -l 4715 $ darcs show files | tr '\n' '\0' | wc -l --files0-from=- |& tail -n1 1343975 total Rather than speed, it may be more important that the darcs theory has needed patching up.
gosukiwi 11y ago
"Pijul" sounds like "dick" in spanish lunfardo :p

104 points by luu 11y ago

jpgvm 11y ago

Couldn't easily work out how it compares to git/svn/mercurial/darcs/bazaar. A comparison to any one of those would do wonders for the landing page.

karaokeyoga 11y ago
Agree. Maybe the "Why a new version control system?" blurb from the FAQ.
gecko 11y ago
It presents the same conceptual UI as Darcs (it's patch-based, not snapshot-based), but provides the performance of Git and Mercurial. It does that by changing the internal storage of how patches work compared to Darcs. If you know Darcs, that's your entire sales pitch: Darcs, but now performant. For everyone else: In Git and Mercurial (and Bazaar, Monotone, Subversion, tla, Fossil, TFS2, and others I'm forgetting), the state is always represented conceptually as a snapshot of the current revision and a pointer to the snapshot of previous revision or revisions, so if you identify that you're at "snapshot 590", and I'm also at "snapshot 590", we're both at the same thing, and both have exactly the same history of how we got there. In a patch-based system, like Pijul or Darcs, that's not true. The state is instead represented by the set of applied patches. These usually have an implicit ordering, but you and I can theoretically have the same patches applied and have a different ordering. (We also can briefly have different resolutions to merge conflicts that result from that, and Darcs' historical inability to deal efficiently with you and me resolving conflicts differently is a major reason it doesn't scale well.) That sounds weird, but can have major benefits. For example, I can now sanely cherry-pick a bug fix from you regardless of the history of that bugfix--and, unlike in Git and Mercurial, Darcs/Pijul will know that the patch I cherry-picked from you is the exact same one that you have on your branch. No duplication, Cherry-Pick: messages, or merge collisions will result if I later pull in your whole branch (or vice-versa). You can also do things like have a patch that has all of your security settings, but always simply not push that when you push out to a public server. (N.B., giving this as an example, not best-practice.) If Pijul works, and can provide Darcs' model in an efficient way, it'd be really awesome. I'm not sure whether it'd be better than Mercurial or Git's model at scale, but it's been really hard to answer that question historically when Darcs itself didn't scale well. Pijul could change that.
- jerf 11y ago
  "That sounds weird, but can have major benefits." I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. It never comes up in SVN or similarly klunky systems, because they're too incidentally complex to notice the underlying essential mismatch. Git and friends, to their credit, made the incidental complexity go away, but I think the essential complexity of their approach is still higher than it ought to be. I wish pijul all the best, because there is room for improvement here. And may I suggest to the pijul team that they really, really want a Pijul-hub as soon as they think they're even remotely ready.
  - gecko 11y ago
    I give git training at work with some frequency. I now briefly discuss this sort of patch-based workflow, explicitly so I can tell people it's not how git works, because in my experience, it's what most people naively expect out of a version control system. Same problem when people try to work out workflows for git. I hypothesize that the reason for the profusion of git workflows is precisely that we really want a patch-based system. Or, in other words, it's not really weird; snapshot-based systems may be weird. I actually agree. I advocated for DVCS-based workflows for a long time, but I think it speaks volumes that I "got" Darcs within about 20 minutes of first seeing it and playing with it, but I know for a fact that, somewhere in the Freenode archives, you can find me saying "The frak is Mercurial? The frak is Git? The frak is this?" as I tried to grok what on Earth they were doing--and this after having taught myself tla! That said, just because something is intuitive doesn't necessarily mean that something is best engineering discipline. I want a Darcs-like workflow to be the dominant one specifically because it's intuitive, but I'm very open to the fact that it might be a really, really crappy way to build a sane (forget performant) large code base. Or it may be exactly what we've always wanted. The simple fact is that I have no idea. This industry, for all the "science" in CS, has got to be the least results-based discipline I'm personally aware of. Pijul will at least permit anecdotal tests of how well patch-based systems scale as a workflow if it takes off, but I'm not holding my breath on someone doing a genuine A/B productivity/trade-off study.

skywhopper 11y ago

Sounds like it aims to be a (much) faster darcs. But between the name and the fact that they are trying to maintain two separate codebases (OCaml and Scala) that both do the same thing, I'm not super optimistic about its prospects.

gecko 11y ago
That should make you more optimistic! They want to make sure that the data format is well-specified from the very beginning, ensuring that there can be a third-party ecosystem that doesn't have the issue Git has right now where the only real definitive definition of Git's data formats is Git, yet people expect libgit2, JGit, etc. to work.
placeybordeaux 11y ago
If you are worried about two languages... >28 October 2015: Discovered Rust, a functional language that is not only type-safe and fast, but also has threads and binds easily to C on Linux and Windows. Looks like a good target.

anton_gogolev 11y ago

> ...snapshot-based systems can be extremely fast, but require an in-depth knowledge of their internals This is false, as demonstrated by Mercurial.

testcross 11y ago
Can you give more details or a link about this please?
- gecko 11y ago
  I think he just means that, while many Git users may indeed be familiar with blobs, trees, commits, packs, refs, remote refs, and so on, most Mercurial users just know that they have changesets. Most Mercurial users do not know what filelogs are, how they work, what the manifest is, and so on. That said, I find the original claim, that users of snapshot systems have to know the internals, a bit idiotic. Subversion users definitely didn't, nor did most CVS users. Git seems to just be a very loud exception. Whether this is by necessity due to Git's UI, or whether it's simply that Git's data structures are more visible and discoverable, is a debate I'm not touching. (I'd note that there's a direct 1:1 correspondence for all core Git and Mercurial internal structures, so it's definitely not inherent in the snapshot model. There are even very nearly 1:1 analogs to older DVCSes, like BitKeeper and Monotone. Git users just tend to know more about the internals of their tooling.)
- IshKebab 11y ago
  Probably not but he is right - all the git tutorials inevitably lead to explaining how git works internally. It is considered necessary knowledge for "grokking" git. Mercurial tutorials aren't like that. It is a lot simpler to use so Mercurial tutorials tend to just tell you how to use it and don't mention the internel implementation details.
Grue3 11y ago
I dunno, Mercurial Queues are pure black magic that only the most advanced dark wizards can possibly understand.

ebbv 11y ago

This seems like a classic case of novice developers thinking it's a great idea to re-invent the wheel. The page gives no compelling reason why I'd want to adopt this over the much more mature solutions out there. I say they are novice because they are maintaining two parallel codebases, which is a mistake no experienced developer would make.

testcross 11y ago
That's why there is only one implementation of git in the world. Oh, wait...
- heinrich5991 11y ago
  They're not maintained by the same team though.
boothead 11y ago
Clearly rank amateurs to develop a working piece of software from category theory.
- jdbernard 11y ago
  Experience in an academic discipline does not imply experience in software development. I don't know the authors, so I hesitate to judge, but starting with two code bases seems like a pretty rookie move to me, at least without a very compelling reason.
  - vezzy-fnord 11y ago
    Just look at those plebeians at Shen.
  - rejschaap 11y ago
    It might not be such a bad idea. If the main goal is to develop a specification or standard then it makes sense to have several implementations. The implementations can be used to flesh out and improve the specification. Also, from their website: Why rewrite it in Scala? The Scala implementation is not competing with the OCaml implementation, we do plan to maintain both in the future. Having several implementations of the core forced us to really think the formats through, and will allow others to write tools in the languages the like best, for their favorite platform (try to get and compile OCaml Pijul on Windows!).

dchest 11y ago

SHA-1 and 32-bit time for a new project in 2015?

elcct 11y ago
This happens if you lock yourself in a basement to code something for couple of years
nsm 11y ago
I understand the 32-bit time not being a good idea, but why is SHA-1 bad for a non-cryptographic application?
- dchest 11y ago
  Because a hash function in version control system is a cryptographic application — it's important to be able to verify the integrity of repository.
  - nsm 11y ago
    Thanks. I am having trouble understanding how crypto would help (I did read [0]). The hash and the files are stored in the same repository. If an attacker edited a file, couldn't they update the hashes of that commit and everything related to it? [0] http://ericsink.com/vcbe/html/cryptographic_hashes.html http://ericsink.com/vcbe/html/cryptographic_hashes.html
    - __david__ 11y ago
      Yes, they could, but that's not exciting (that's really what `git --amend` and `git rebase` are, after all). What's interesting from an attacker point of view is changing the contents of the file (in a meaningful way) without changing the hash. That way anyone who pulls from you gets a different copy of the code, but they won't easily discover if since the hash is the same as the original copy. Think about what happens if you were to fork a copy of something on github and then rebase to edit one of the commits. If I pulled from your copy and the pulled from the official repo I'd get a merge (and probably some conflicts) because git identifies commits by their sha and uses that to decide what needs to be merged. But if you managed to change one of your commits without changing the sha, then I'd have a much harder time detecting it, since when I pulled from another repo later there would be no merge (even though things were actually different).

andersonmvd 11y ago

Is git that broken? To focus on replacing VCS, you should have a big reason for that I think. I'm just curious.

krupan 11y ago
git is an example of an amazing and powerful new VCS paradigm (distributed), but I sure hope we are not done making better and better tools, like, ever.
- andersonmvd 11y ago
  I also hope we are not done making better and better tools, but to make something better, you need find some gap in current technology and fix it. That's what I am asking: which are the gaps fixed by this VCS? Or in simple terms, why should I switch?
  - mitchtbaum 11y ago
    I personally like very much how Golang and Rust have started to make low-level (mostly old and very important) applications more maintainable for a wider range of contributors (and readable for me); I see (coreutils)[0] as a great example. Also, I would throw Lua into that mix too, at least on some level. As it applies to this particular case, for instance, a repo object management function for lua-git, git implemented in Lua, (`Tree:checkout(path)`)[1] seems like something I could understand. I failed to find git's checkout function, even with a good bit of energy put into it. 0:https://github.com/uutils/coreutils https://github.com/uutils/coreutils 1:https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc971a8802f74a1921e0187e/lua/git/objects.lua#L84 https://github.com/mkottman/lua-git/blob/d64218a227fe26b1fc9...
  - WorldMaker 11y ago
    Git is a representation of history as a directed acyclic graph (DAG) of commits full of trees that are the state of the repository at the time of the commit. That DAG is strictly ordered (commits point to their parents and this is part of their identity so changing a commit parent makes a new incompatible commit). Darcs (which predates git, by the way) represents a repository as a loosely ordered set of patches (just the changes, not the full state at any given time). Darcs works to know how to rearrange patches in time to create new states. The difference/benefit to this approach is best illustrated with cherry-picking: in Darcs it is very easy to state that I want the patches my fellow developer created for modules X and Y, but I don't think he's done with module Z yet so I'm going to skip those. The patches can be interleaved and recorded in any order and Darcs will do all the hard work of figuring out how to grab just the ones I want, and do so without changing the physical identity of those patches (they are still the same patches my coworker developed). When this works, and it works 98% of the time without an issue, it is a wonderful magic. (Contrast this to git cherry-pick which builds new commits and is likely to have future merge issues with the commits it was built from, even those commits are somewhat "the same".) Pijul is an attempt at getting some of the same magic of a patch-oriented approach (and smarter patch merging) in a post-git world. Also, it's definitely early to talk about switching to Pijul.

zaphar 11y ago

Looks like a faster darcs. For anyone who has never used darcs a brief description is in order. Darcs is a revision control system based on something called "Patch Theory". That gives it some interesting properties. But for the user this translates into the possibly the clearest easiest to use interface of any DVCS out there bar none. It's merges are the least painless of them all in my experience. t's glaring flaw though is that it has historically been really slow as the repository grows in size. They've improved this since but it still can't compete with git and hg on speed. If it were faster though I'd use it in a heartbeat. Pijul looks to be a refinement of the darcs algorithms and thus much faster as a result. I'll definitely be watching them as they progress.

maaku 11y ago
You didn't really say what "patch theory" is. Can you describe or provide a link?
- zaphar 11y ago
  https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theory https://en.wikibooks.org/wiki/Understanding_Darcs/Patch_theo...
emmelaich 11y ago
> It's merges are the least painless Least painful - presumably :-) But I have heard that if things don't go well it's much harder to fix up.
gnufx 11y ago
It's been practical enough for me for a repo of this size for several years: $ darcs get http://arc.liv.ac.uk/repos/darcs/sge &>/dev/null $ cd sge $ darcs log --count 4851 $ darcs show files | wc -l 4715 $ darcs show files | tr '\n' '\0' | wc -l --files0-from=- |& tail -n1 1343975 total Rather than speed, it may be more important that the darcs theory has needed patching up.

gosukiwi 11y ago

"Pijul" sounds like "dick" in spanish lunfardo :p