[HN Gopher] Darcs, Friendly Version Control
___________________________________________________________________
Darcs, Friendly Version Control
Author : tusslewake
Score : 59 points
Date : 2025-02-12 05:00 UTC (3 days ago)
(HTM) web link (darcsbook.acmelabs.space)
(TXT) w3m dump (darcsbook.acmelabs.space)
| quesera wrote:
| I miss darcs very much. Easily my favorite VCS ever.
|
| 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?
| gavinhoward wrote:
| If you loved darcs, check out Pijul. They solved the
| exponential problem with first-class conflicts.
|
| Disclaimer: I am making a competitor to Pijul, but Pijul really
| is the spiritual successor to darcs.
| leonheld wrote:
| Sadly my only experience with Pijul was this
| https://github.com/Eugeny/russh/issues/151.
|
| 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.
| gavinhoward wrote:
| I can see your point.
|
| 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.
| kstrauser wrote:
| That's a classy reply.
| kstrauser wrote:
| 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.
| gavinhoward wrote:
| Yeah, I don't know why you were downvoted. I upvoted you
| because I was sure you were replying to me sincerely.
| nmz wrote:
| Linus called cvs/subversion broken, did you stop using git?
| adastra22 wrote:
| I like the idea of Pijul, not the implantation (so far). What
| are you building and where can I get it?
| gavinhoward wrote:
| It is not ready yet, sorry!
| networked wrote:
| 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.)
| gavinhoward wrote:
| You are absolutely right.
|
| 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.
| macawfish wrote:
| 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.
| gavinhoward wrote:
| Mine will allow cloning _all_ data, including issues, PRs,
| and real-time chats (Zulip-style). I think that might cover
| your bases.
| JTyQZSnP3cQGa8B wrote:
| > Is the world a better place now?
|
| 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.
| quesera wrote:
| 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. :)
| simonmic wrote:
| You may be right, and I think jujutsu or a fork of it is
| the most likely contender.
| hvenev wrote:
| I think git is quite nice and easy to work with once you
| realize one thing: git is first and foremost a filesystem.
| Version control is built on top.
| James_K wrote:
| 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.
| kgwgk wrote:
| "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."
| ltbarcly3 wrote:
| The probability of working software resulting from this
| operation is approximately 0.
| hsenag wrote:
| Even if previous VCSes (edit: other than Darcs) used diffs
| internally to store changes efficiently, they were still
| inherently snapshot based.
|
| I think Git's advantage was mainly from using Merkle trees
| rather than specifically that it was snapshot based.
| adastra22 wrote:
| To be clear, darcs is neither diff nor snapshot based.
| sunshinerag wrote:
| What is it based on then?
| hsenag wrote:
| 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.
| bernds74 wrote:
| To me this has always sounded like the kind of error-
| prone excessive cleverness that I wouldn't want anywhere
| near my version control system.
| ltbarcly3 wrote:
| It's a thing that nobody is smart enough to use and
| didn't actually work, but hey at least Darcs is also
| 1000x slower than git and will lose data!
| hsenag wrote:
| 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.
| adastra22 wrote:
| It's the same thing that happens every time you rebase or
| cherry pick commits in git.
| Nullabillity wrote:
| A version control system always needs to consider both,
| to some extent.
|
| The difference is in which is the primary source of
| truth, and which is calculated when required (and then
| thrown away).
| adastra22 wrote:
| This isn't about snapshot vs diff. It is about tree of changes
| vs. bag of patches.
| WolfeReader wrote:
| 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.
| JTyQZSnP3cQGa8B wrote:
| > which remembers previous conflict resolutions
|
| 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.
| reshlo wrote:
| > 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.
|
| https://git-scm.com/book/en/v2/Git-Tools-Rerere
| ltbarcly3 wrote:
| Cheap branches are important. Git is no worse and in most
| cases far better than any other VCS when it comes to
| conflicts.
|
| 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.
| mdaniel wrote:
| 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
| ltbarcly3 wrote:
| 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.
| kelnos wrote:
| Git does indeed remember conflict resolutions (if the
| ReReRe feature is enabled), but in practice it's only
| helped me a handful of times.
|
| (And I am big on obsessively rebasing and cleaning up
| history before pushing a change.)
| Nullabillity wrote:
| Merging works fine, as long as Git knows how to resolve the
| ancestry. Rebasing breaks that (save for hacks like
| rerere).
| ltbarcly3 wrote:
| 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.
| abraae wrote:
| Darcs to me is a bit like VHS vs betamax. A superior technology
| that did not win in the market due to other factors.
|
| 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.
| ltbarcly3 wrote:
| 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)
|
| https://en.wikipedia.org/wiki/Darcs#Shortcomings
|
| Darcs was and still is unusable and inferior.
| abraae wrote:
| 1000x is a bit hyperbolic but I'll admit I had forgotten the
| purgatory of slow version control. You are correct about
| that.
| dan-robertson wrote:
| Darcs has exponential time merges so there is definitely
| potential for getting in very slow situations.
| woadwarrior01 wrote:
| 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.
| gre wrote:
| It got to the point where I had a darcs commit take more than
| ten minutes. That's when I stopped using darcs.
| simonmic wrote:
| 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.
| atombender wrote:
| 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.
| egl2020 wrote:
| 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.
| simonmic wrote:
| Sounds bad. Is that reproducible today I wonder.
| CountSessine wrote:
| 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.
| CountSessine wrote:
| Maybe they've fixed this since then. I haven't looked at darcs
| in AGES.
| bitwize wrote:
| Use Pijul instead. It uses the theory of patches from Darcs, does
| not have the exponential-merge corner case, and is written in
| Rust.
| andrewl wrote:
| 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?
|
| [1] https://fossil-scm.org/
| spit2wind wrote:
| 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.
| pyrolistical wrote:
| Seems like darcs applies patches and diffs trees, whereas got
| applies patches and diffs commits.
|
| Trees don't contain author or timestamps, unlike commits.
|
| This makes it easier to achieve "same state" by comparing trees.
___________________________________________________________________
(page generated 2025-02-15 23:01 UTC)