Darcs, Friendly Version Control
darcsbook.acmelabs.space
darcsbook.acmelabs.space
Way back in the day we did some due diligence on our source control - at that time CVS - and settled on darcs as the most elegant.
Around the same time Linus created git and the rest is history and eventually darcs went the way of betamax.
Darcs was never good enough, not even close. It wasn't even good. It fundamentally failed at the most basic thing required of version control, that you can actually use it to get work done, because it became so slow with even small codebases that you had to give up and switch to SVN. You could have a codebase with 200k lines of code and basic operations would take 30 MINUTES or longer. (not to mention that darcs would lose data, and you could get in situations where conflict resolution was impossible and you would just be stuck and forced to manually fix things outside of VC)
https://en.wikipedia.org/wiki/Darcs#Shortcomings
Darcs was and still is unusable and inferior.
If you do encounter a slow merge with darcs, the normal practice is to treat that as a mistake, step back and re-do your commits to be less conflicting - not to waste time waiting, ending up with a very slow merge in your history.
The original exponential merge corner case, and subsequent lack of a clear prevention mechanism or even clear description of the issue, has had a big anti-marketing impact, and has probably kept darcs out of the limelight ever since the departure of the original lead developer, despite a small heroic band of maintainers working on it to this day.
However, we were constantly hitting the exponential merge conflict bug. Darcs messed up our repo state several times and cost us days of productivity. It had nothing do with the size of the codebase; as far as I remember, all that was needed to trigger the bug was to make a patch that happened to include the same code line change as someone else. It felt ridiculously fragile. As far as I remember, once you hit the bug, your repo was beyond saving. You had to roll back to a backup.
We still stuck by Darcs until around 2009-2010 when it was pretty obvious the writing was on the wall and Git was going to eat the world, in large part thanks to GitHub.
Avoid: Pijul. I doubt it will succeed in getting wide adoption. Some of the reasons already covered by others comments in this thread so don't want to repeat.
Wish: I really wish darcs was rebooted and made a comeback. What can we do to make it happen? I heard a version 3 is a work in progress. I am also aware of this new initiative (GitHub equivalent but for darcs): https://smeder.ee
The biggest thing we need is more developers.
It didn’t really seem to me at the time like this was an appropriate VCS for a team of developers using CI.
I did not love building the binary from Haskell sources. The ghc compiler was awkward and slow at the time.
I did not love the exponential time explosion for complicated (in practice, just "large") patch histories.
Both of those problems were 20 years ago though. Is the world a better place now?
Disclaimer: I am making a competitor to Pijul, but Pijul really is the spiritual successor to darcs.
When one of the key guys behind the VCS says things like "especially when the alternative is something as broken as Git" about other control systems I really don't feel like using said tool.
This is a good reminder to me that I need to control my tongue as well; I have said things like the Pijul author did in that thread, and I need to do better.
Its not damning to call something broken, plenty of software has bugs that make it unusable and are broken to many people. In fact, many tools have been made in anger at other tools not doing what you want them to do. This is just the software inception cycle. You should be allowed to be angry at the brokenness of software... its what allows improvement.
To be honest, though, I don't want to even mirror that repo on GitHub. Not doing so means I don't have to agree on their onerous T&C for that code.
I was planning on streaming my work on Twitch once I truly get started. I was hoping that might be a goid place for updates.
They claim rights above what FOSS licenses allow, and I do not want that.
I do not want my code to end up in their LLMs. Yes, I have blocked them from my self-hosted forge too.
Yes. [1] But that is only chat/discussions.
In the future, Yore might get real-time collaboration like Google Docs, but that depends on it taking off.
> I'm curious to understand if the underlying data structure functionality will be usable as a library.
Yes. [2]
[1]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yore/d...
[2]: https://git.yzena.com/Yzena/Yc/src/branch/master/docs/yore/d...
Don't ask me because the only SCM I have been using for the past 15 year is git and I hate it. Every company uses it, I made a lot of PowerPoint presentations to teach people how to use it, yet I refuse to use its command-line.
I switched from SourceSafe/SVN/Mercurial to git, but never used Darcs. IMHO git is fine as an assembly language of SCM, but I'm trying to switch to jujutsu which has a better CLI while staying compatible with git as a backend.
I liked arch. I loved darcs, but it blew up on me.
I liked hg, but it was clear that git was going to win, so I capitulated.
Honestly, the worst thing I can say about git is that it's always good enough.
Yes, the CLUI has historically been a dog's breakfast. It seems like some slow improvements are being made, which is great, probably -- I haven't learned them.
But once you get past that mostly-psychological barrier, or if you bypass it completely with a GUI etc, the underlying technology is solid and reliable.
I postulate that VCS is "finished" and that any new tool will need to use git underneath for wide adoption. I hope I'm wrong and someone more creative than I can make me love a VCS again. :)
What I keep meaning to try is Fossil[1], built by the creators of SQLite. (And built on SQLite.) It’s not that we’re looking to replace Git. I’m just curious about the actual hands on experience. Has anybody here actually used it, as opposed to looked at it?
The project is super well put together. It's so refreshing compared to the dumpster fire that is git. The commands make sense, the documentation (if even necessary) makes sense, and the code of Fossil itself is easy to compile and hack on.
The community is nice, too. I really appreciate Dr. Hipp's approach to software.
Trees don’t contain author or timestamps, unlike commits.
This makes it easier to achieve “same state” by comparing trees.
I think Git's advantage was mainly from using Merkle trees rather than specifically that it was snapshot based.
A Darcs patch is somewhat like a diff, in that most patches will describe a sequence of text to be removed and added from specific points in each file.
But: Darcs patches add:
- The ability to work out precisely how to apply the same patch in a different context in a reproducible way (or to refuse to do so if it can't do it safely) - More "semantic" kinds of change such as replacing all occurrences of a token in a file, or renaming a file. In both cases this will merge cleanly and reproducibly with other changes to the same file.
Most VCSes including git have some level of complicated algorithms behind them. Darcs does have significant weaknesses when it comes to handling conflicts but the core logic of figuring out how to apply changes to files has been pretty solid for its entire existence.
The difference is in which is the primary source of truth, and which is calculated when required (and then thrown away).
This may seem trivial, but the darcs/pijul approach permits an entirely different, more distributed/decentralized development model.
Ironically a model better suited to kernel development.
In darcs/pijul, the state of the repository is a *set* of order-independent changes/patches. I don't know about darcs, but pijul even uses clever homographic hashing so that the commit hash after applying patches A, B, and C (in that order) is the same as if you did C -> A -> B, or any other permutation.
In Linux kernel dev, for example, developers think of a particular build as "upstream 6.13.2 with zfs and realtime patchsets applied" but in reality in any given instance it is actually "6.13.2 -> zfs -> realtime" or "6.13.2 -> realtime -> zfs" depending on which order you cherry-pick/rebase the patches. Both have different git hashes and are properly speaking different things. In pijul it would be "6.13.2 + zfs + realtime" and the order doesn't matter.
1. A much better merging strategy which remembers previous conflict resolutions. This is possible in both diff and snapshot VCS's.
2. Distributed repositories. Instead of storing history in one centralized server, which is prone to several kinds of failure, Git/Darcs/Hg/Fossil etc. all replicate history to each client by default. This makes it very difficult to actually lose code or history, which definitely happened in older centralized systems.
IMHO this is far from the truth. git is a mess with conflicts and nothing is remembered. When you rebase an old branch a few times, you stumble upon merge conflicts every time you have to rebase that old code. It's really infuriating.
I think git became popular for 2 reasons: cheap branches, and Linus Torvalds.
If you are getting conflicts over and over you should change your pattern of use to stop causing them, it's quite possible to do.
I've never had any major frustrations with 'lots of conflicts'. There's something peculiar about what you are doing.
I would sit down and write down what the 'features/benefits' are of your current git workflow. Then you can brainstorm about things you can change about what you are doing to get those benefits without the frustrations (like maybe you don't need to rebase as much or at all, or you can avoid rebasing work branches and just squash the final commit on top of main, I don't know what you are doing but my point is there are endless variations of how to collaborate on git and lots of them don't cause 'lots of conflicts'), and then work with your team to get them. When you are successful they will thank you for making their lives less frustrating. Or you can be secure in the belief that there's nothing you can do, either way.
(And I am big on obsessively rebasing and cleaning up history before pushing a change.)
Apart from making merging much much less painful, the huge selling point was that SVN was extremely slow. Changing branches required chatting with the server in most cases, and could take a minute or two. You couldn't just switch back and forth between branches.
Which is directly solved by being a DVCS, yes. Your second paragraph contradicts your first.
Darcs and Pijul can change branches very rapidly despite being diff-based, because they too are DVCS (and the inverse patches basically already got computed upon commit, so it's easy on the CPU).