git is the superior technology. If you weren't around back in the day, one of the big problems with version control was how SLOW it was. Changing branches on a moderate sized codebase in SVN took a long time, and SVN was considered quite fast. When we finally got git we couldn't believe it actually did something. Like you would change branches and it would instantly return, and you would scratch your head and double check that the files were different? It was the difference between 30s of your CPU grinding and 45ms. This was so completely frustrating that long before git became dominant we were all using git-svn so at least we wouldn't be forced to use SVN locally, because it was horrible. Darcs was 1000x worse than that.
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)
Tired of and a bit amused by the Betamax trope. When VHS debuted with a two hour recording time, Betamax couldn’t hold more than an hour’s worth of video, making it a horrible fit for most films and sports. The workarounds for this involved compromising the picture quality advantage. Beta was also more expensive. This was not some case of being outmarketed, or unlucky: Betamax was worse technology than VHS. And while git’s design leaves much to be desired (which modern VCSs like jj make clear), there is a helluva lot of great technology in it.
I wanted to point this out also! The entire meme of "better technology that lost in the market" really appeals to a certain kind of person who is somehow always also intolerable.
Yeah, there was a lot of FUD being spread around Darc's exponential merge corner-case. We were using it with a medium sized codebase (~50k lines) and never encountered that issue. Anyway, we begrudgingly moved to mercurial a few years later and then onto git, further along the road. With every step, the tooling got worse.
I was on a small team using Darcs around 2005-2008, and I was a big fan of it, evangelizing as much as I could.
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.
At a certain point darcs was fixed to make the exponential merge case much more rare, though it has never been entirely removed. At least from that point on, it has always been possible to use darcs productively just by avoiding or working around those very conflict-heavy merge scenarios. Regular darcs users internalise those working habits and so rarely encounter the problem in practice.
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.
We were using Darcs on what was then still a small code base and already started running into operations sometimes taking tens of minutes. Not knowing if an operation would end sometime during our lifetime is pretty annoying. Git, though conceptually worse, felt like a breath of fresh air once we migrated.
For now: Give Jujutsu (https://jj-vcs.github.io/jj/latest/) a try, it's good whilst maintaining a level of compatibility with git which is good for gradual adoption and uptake.
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
I used Darcs a long time ago and what I remember was that because it reordered patches, it was actually quite difficult to do a bisect to find a patch that broke a build. Unlike git where you can completely characterize a build with the HEAD sha, darcs didn’t really have that concept and it was very tricky to figure out what actually went into a particular build.
It didn’t really seem to me at the time like this was an appropriate VCS for a team of developers using CI.
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.
I can’t still edit that comment to explain, but I meant it sincerely. When someone sees a foible of their own in others and moves to correct it, that’s awesome and commendable.
Eh, you never can tell. I assume someone thought I was being sarcastic. I don't care if someone downvotes me, but I'd hope it'd be because I'd genuinely said something dumb or unkind.
Well he didn't really call cvs/subversion broken, to semi quote, he basically said that subversion people were trying to improve on cvs and you cannot do that because cvs is inherently broken.
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.
Probably a good idea to have a place where those who are interested can wait for an update.
You can create a mailing list or a GitHub repository that one can star or watch today.
(Later, you could use the repository to mirror the source code of your VCS.)
I wonder if you're open to making something that can double as a p2p data store for collaborative p2p applications, including web apps? That was always my wish for pijul, that I could use it in this way.
Do you mean that your system will have some built-in collaboration features? Sounds pretty cool. I'm curious to understand if the underlying patch data structure functionality will be usable as a library to build custom stuff on top?
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.
My path was cvs -> svn -> arch -> darcs -> hg -> git
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. :)
I used and rather liked Darcs in the dark ages when SVN was the best alternative. Then I discovered that it would happily accept largish binary files, but would later refuse to give them back when I needed them. I could have lived with an error on check in.
We moved from Subversion to Git a long time ago, and we’re fine with it. But we’re only 16 users, so I personally can’t speak to how well it works for much larger teams, although I know of course that it’s used by giant teams for giant projects. One of the advantages is that so many people know it. So even if the features and user experience were worse, it could still be the best choice because almost everybody you’ll need to hire will have experience with it.
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?
I've been using Fossil for personal projects and love it. It's maybe best to think of Fossil as GitHub in a box. Fossil comes with a server that includes tickets, a wiki, and a live chat space in addition to the version control. I work on my phone on the bus, start the server (`fossil server`) in Termux when I get home, and then access that on my computer.
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.
I would say that jujutsu is at least as compelling as Pijul in conversations where either is valid to implement. Migrating off of Git cold-turkey is a high barrier for some, and jj lets you defer that requirement via high-quality interop.
It seems odd that they boast about being patch based, given that the original advantage of git was that it uses snapshots instead of diffs as previous VCs did.
Git (and nearly every other version control system) the state of the repository is an ordered list of changes. This is massively oversimplified of course, as in git it is a tree rather than a list as in CVS/SVN, and git is actually storing snapshots rather than diffs, but whatever. That doesn't matter here. Traditional version control is an ordered list of changes, and that ordering is what matters here.
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.
It's based on "patches" (which was what the original comment was referring to).
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.
You could always go back to emailing around file changes :-)
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.
"In our dependency graph you can also see that all our changes concerning the files A and B are totally independent from each other. So I could pull only the changes concerning B from the repository while ignoring the changes regarding A altogether. This is an incredibly powerful mechanism that snapshot based version control systems do not have. Now you can pull in a set of patches and ignore all those that don’t depend on the change you are currently interested in. Other version control systems like git for example call this cherry picking, but compared to darcs they are suffering from some short comings. In those version control system you re-record the patch when you cherry pick it. That means that its whole identity changes, one way in which this manifests is that it will get a different hash. So even though it’s the exact same change the patches are now different. This can become quite annoying when working in a distributed setting, with darcs this is a complete non-issue."
No. The advantage of Git (and Darcs, Hg, and others) over SVN/TFS is twofold:
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.
> The git rerere functionality is a bit of a hidden feature. The name stands for “reuse recorded resolution” and, as the name implies, it allows you to ask Git to remember how you’ve resolved a hunk conflict so that the next time it sees the same conflict, Git can resolve it for you automatically.
You say that as if using git isn't a team sport. I only have control over my behavior, and that goes double for what happens after $(git pull) or its $(git rebase) friend
If only there were a way to influence the behavior of other humans...
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.
Being able to merge code is important, distributed repositories is nice but nobody switched to get that.
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.
"Changing branches required chatting with the server in most cases, and could take a minute or two."
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).
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.
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.
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.
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
https://hub.darcs.net/
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?
[1] https://fossil-scm.org/
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.
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.
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.
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.
https://git-scm.com/book/en/v2/Git-Tools-Rerere
(And I am big on obsessively rebasing and cleaning up history before pushing a change.)
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.
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).