I only know, because I was trying to send a patch to a project hosted on nest.pijul.com, but I think Nest is also in a bit of a broken state at the moment. At least, I couldn’t make it work.
Maybe Pijul works fine locally. It’s been in the rewrite state for quite a bit, though, so the current code is not really maintained.
Yeah, I want to like pijul, but I was put off by the fact that they refuse to open-source Nest. That means I can’t self-host, and it was a warning sign that the development style in general is not as open as I’d like. That they’ve been in closed rewrite for over a year is another yellow flag.
I couldn’t care less about Nest (although I completely get those who do!), but the fact that they’re on their third rewrite, none of which have existed long enough to actually get stable or usable, is a much bigger issue IMVHO.
We’ve indeed tried different languages before settling on Rust, and we have had preliminary things in OCaml and Scala. But we’ve had a public version for years now, written in Rust.
This comment makes me think that there actually three different classes of opinions:
those who think the development is “too opaque”, even though they never contributed anything when it was more open, and don’t know anything about the reasons why the new version is not public yet.
those who think there have been too many released versions (or “rewrites”), meaning that the development is actually too open for them.
I can also guess that some don’t really mind not having a half-broken prototype version to complain about, as long as they get a working, open source version in the end.
Something I’ve read before about Pijul, is that you can’t self-host without having unlimited access to the Nest’s source code. This is actually false: you can totally setup another machine with Pijul installed, and push/pull your patches between the two machines. No need for a web interface for that, SSH is enough.
Sure, and fair enough. I like having a web interface for browsing my shelved projects and examine history (and, rarely, showing to other people), though, and my concerns about openness remain.
As the author of the Nest, I have written a number of times that I believe the Nest should and will be open in the long term, but Pijul is a large open source project to manage already, including its many dependencies (Rust crates Sanakirja and Thrussh, for example). At the moment, opening the Nest would simply not be feasible in terms of work time and extra maintenance. In the future, when things settle down a little on the Pijul front, this situation is likely to change.
Looking up in the changelog for the latest Darcs version 2.16.1 (emphasis mine):
Preliminary UNSTABLE support for a new patch theory named “darcs-3”, largely based on the pioneering work of Ian Lynagh for ‘camp’.
Please note that this format is not yet officially supported: some features (like conversion from older formats) are still missing, and we have not yet finalized the on-disk format. You should NOT use it for any serious work yet.
The new theory finally solves all the well-known consistency problems that plagued the earlier ones, and thus fixes a number of issues (including issue1401 and issue2605) that have been outstanding for many years. It also reduces the worst case asymptotic runtime for commutation and merging from exponential to merely quadratic in the number of patches involved.
One of the reasons we are confident this new theory and its implementation is sound, i.e. respect all required properties, is that we have improved our test case generator for sequences of patches. It now generates all possible conflict scenarios. Since the new theory no longer has worst case exponential runtime, we can and did test all required properties and invariants with a large number of generated test cases (up to 100000).
Can somebody report how the problems manifests in real life and what are the workarounds? Does it mean that using darcs now, i.e. before “darcs-3” patch theory becomes mature is dangerous?
Darcs had/has a “poison patch” issue where one patch may trigger very long checkout times, up to a point where it would render your repo useless. Most people would never have that problem, but it did happen to me back in 2004, and I then switched to Mercurial after trying Monotone and Git. You may want to check out Pijul, as it’s the spiritual successor of Darcs.
Uh, I’m trying to remember. If I remember right, darcs had an issue around branches that would go to far away from each other. As darcs tracks which patches are needed to apply a certain patch, this lead to a problematic behaviour. From my experience, that was unlikely, but of sufficient likeliness that it became an issue, especially on large repositories. There’s fixes for that, but that’s a space where you need deep knowledge of darcs, which is kind of against the ethos of the project in trying to go an extra mile for making their technology accessible. (For the last part: I was lurking darcs for a while and tried contributing 1-2 patches)
When a conflict between Alice and Bob is solved in two different ways by Alice and by Bob, this generates a new conflict. If they keep doing that n times, applying the patches in Darcs used to be in time 2^n. Solving that is really cool, because AFAIK no one really understood until recently what Darcs was doing in that case.
Conflicts are a little strange in Darcs, since there is no notion of “state”, so coming back to a conflicting situation (with e.g. darcs revert, or darcs rollback) is always going to be a little bit weird.
The “every repo is a branch” and “Master and Working Repositories” workflows also in Git by cloning the upstream repo, then cloning local “branch” repos from it. When you’re done, push to the local “master”, and then eventually back to upstream. You’d miss out on a lot of Git functionality, but it should work.
Personally, I think the Darcs way of doing it is really annoying. I like being able to keep around experimental branches, WIP features and bug fixes, etc. without cluttering my file system. And I like being able to push them all somewhere and clone them in different places with a single “git clone …”. I know under the hood Git’s keeping all that data around, but it’s hidden away in .git where I don’t have to think about it.
Neither have I, hopefully I can at least encourage people to learn/use git reflog. Its rare you need it but comes in super handy when you’ve made a mistake.
It’s been a while, but as far as I remember, Darcs generally works in a way a bit different from git: it downloads all patch metadata, figures out which patches it needs to reconstruct the current work tree and then downloads the data. So binaries are at least not part of the bundle you usually work with.
AFAIK, it works quite well with them. I know it’s been a promoted strong-point of pijul.
Slightly heretical question, but is the patch theory actually necessary for the user friendliness? as far as I remember the main thing about darcs in practice was just that it had a really thoughtfully, well written CLI.
It sounds like a good idea, but I’ve never ran into the problem described in “Why darcs?“ section. I don’t why would two people work on the same feature independently?
someone adds a feature at the same time someone else adds cross-cutting functionality (e.g. i8n or l10n)
someone fixes a bug while someone else fixes a different bug that touches the same code
This is more important for development that doesn’t have a central coordinating authority, so you can’t say “I’m going to work on X” and ensure nobody else touches X. Lots of open-source projects operate like that.
topic drift… but anyone tried https://pijul.org/, a new VCS, that claimed to solve the exponential merge time?
Pijul is being rewritten: https://discourse.pijul.org/t/is-this-project-still-active-yes-it-is/451
I only know, because I was trying to send a patch to a project hosted on nest.pijul.com, but I think Nest is also in a bit of a broken state at the moment. At least, I couldn’t make it work.
Maybe Pijul works fine locally. It’s been in the rewrite state for quite a bit, though, so the current code is not really maintained.
Yeah, I want to like pijul, but I was put off by the fact that they refuse to open-source Nest. That means I can’t self-host, and it was a warning sign that the development style in general is not as open as I’d like. That they’ve been in closed rewrite for over a year is another yellow flag.
I’ll check back in with it in a couple years.
I couldn’t care less about Nest (although I completely get those who do!), but the fact that they’re on their third rewrite, none of which have existed long enough to actually get stable or usable, is a much bigger issue IMVHO.
I’d be fine if they rewrote it ten times, as long as the process was open! Or at least transparent.
Haven’t they been rewriting it for over 2 years now?
Third already? Where did you get that from?
They had two older implementations in OCaml and Scala, and are currently rewriting in Rust. Am I missing something?
Disclaimer: I’m one of the authors.
We’ve indeed tried different languages before settling on Rust, and we have had preliminary things in OCaml and Scala. But we’ve had a public version for years now, written in Rust.
This comment makes me think that there actually three different classes of opinions:
Something I’ve read before about Pijul, is that you can’t self-host without having unlimited access to the Nest’s source code. This is actually false: you can totally setup another machine with Pijul installed, and push/pull your patches between the two machines. No need for a web interface for that, SSH is enough.
Sure, and fair enough. I like having a web interface for browsing my shelved projects and examine history (and, rarely, showing to other people), though, and my concerns about openness remain.
As the author of the Nest, I have written a number of times that I believe the Nest should and will be open in the long term, but Pijul is a large open source project to manage already, including its many dependencies (Rust crates Sanakirja and Thrussh, for example). At the moment, opening the Nest would simply not be feasible in terms of work time and extra maintenance. In the future, when things settle down a little on the Pijul front, this situation is likely to change.
Looking up in the changelog for the latest Darcs version 2.16.1 (emphasis mine):
Can somebody report how the problems manifests in real life and what are the workarounds? Does it mean that using darcs now, i.e. before “darcs-3” patch theory becomes mature is dangerous?
Wait, this seems like huge news to me!?
Can’t find anything more recent than 2011… is there a paper?
Darcs had/has a “poison patch” issue where one patch may trigger very long checkout times, up to a point where it would render your repo useless. Most people would never have that problem, but it did happen to me back in 2004, and I then switched to Mercurial after trying Monotone and Git. You may want to check out Pijul, as it’s the spiritual successor of Darcs.
Uh, I’m trying to remember. If I remember right, darcs had an issue around branches that would go to far away from each other. As darcs tracks which patches are needed to apply a certain patch, this lead to a problematic behaviour. From my experience, that was unlikely, but of sufficient likeliness that it became an issue, especially on large repositories. There’s fixes for that, but that’s a space where you need deep knowledge of darcs, which is kind of against the ethos of the project in trying to go an extra mile for making their technology accessible. (For the last part: I was lurking darcs for a while and tried contributing 1-2 patches)
There are two issues:
When a conflict between Alice and Bob is solved in two different ways by Alice and by Bob, this generates a new conflict. If they keep doing that n times, applying the patches in Darcs used to be in time 2^n. Solving that is really cool, because AFAIK no one really understood until recently what Darcs was doing in that case.
Conflicts are a little strange in Darcs, since there is no notion of “state”, so coming back to a conflicting situation (with e.g. darcs revert, or darcs rollback) is always going to be a little bit weird.
Solving point 1 is big news.
This is by far my favorite version control system. Unlike git, I find branching in darcs intuitive and easy to understand.
Darcs doesn’t support branching in the same sense as Git, so I’m not sure that’s a fair comparison.
The “every repo is a branch” and “Master and Working Repositories” workflows also in Git by cloning the upstream repo, then cloning local “branch” repos from it. When you’re done, push to the local “master”, and then eventually back to upstream. You’d miss out on a lot of Git functionality, but it should work.
Personally, I think the Darcs way of doing it is really annoying. I like being able to keep around experimental branches, WIP features and bug fixes, etc. without cluttering my file system. And I like being able to push them all somewhere and clone them in different places with a single “git clone …”. I know under the hood Git’s keeping all that data around, but it’s hidden away in .git where I don’t have to think about it.
I’d love to hear more about how darcs’ branching is different than git’s. Care to give us some more insight?
Indeed. Unlike git, I never find myself needing to
rm -rf .my darcs repo.I’ve never needed to do that to a git repo either
Neither have I, hopefully I can at least encourage people to learn/use git reflog. Its rare you need it but comes in super handy when you’ve made a mistake.
Do you by chance know if darcs how darcs supports big non-text files?
It’s been a while, but as far as I remember, Darcs generally works in a way a bit different from git: it downloads all patch metadata, figures out which patches it needs to reconstruct the current work tree and then downloads the data. So binaries are at least not part of the bundle you usually work with.
AFAIK, it works quite well with them. I know it’s been a promoted strong-point of pijul.
Slightly heretical question, but is the patch theory actually necessary for the user friendliness? as far as I remember the main thing about darcs in practice was just that it had a really thoughtfully, well written CLI.
I love darcs, and used it for a while for personal projects, …. but now all is git, it seems
It sounds like a good idea, but I’ve never ran into the problem described in “Why darcs?“ section. I don’t why would two people work on the same feature independently?
A couple reasons come quickly to mind:
This is more important for development that doesn’t have a central coordinating authority, so you can’t say “I’m going to work on X” and ensure nobody else touches X. Lots of open-source projects operate like that.