4 ms·

Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github.

by gnufx 6y ago

Hear, hear, except that Darcs' philosophy lives on in Darcs, thanks to Ben Franksen particularly, and I don't think the world needs anything else like Github. An "experimental" implementation of the Darcs 3 theory is in the current release https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG https://hub.darcs.net/darcs/darcs-2.16/browse/CHANGELOG

atombender 6y ago
Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.
- bb88 6y ago
  > For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. To be fair though, it's a source tracker which are usually small-ish text files. It's not really meant to be a Digital Asset Manager, say. Git can do a shallow clone as well for very large repos. Much of that deep information becomes probably useless over time, unless you're doing code archaeology.
  - atombender 6y ago
    Well, the thread is about what comes after Git. If you ask me how Git could be improved, then what it's "meant" for doesn't matter if there are unsolved use cases. Also, there's no particular reason Git couldn't be modified to work well with large files.
    - bb88 6y ago
      > Git couldn't be modified to work well with large files. Apologies for the late response. Yes. I absolutely agree with that. The trick though is that when changes happen to a large file, what's the best way to do a diff? What if it's bzip2 or encrypted? The other issue is that stagnant large files in your history need to be pruned. I'm not sure how to do that in git right now other than rewrite history.

by gnufx 6y ago

atombender 6y ago

Interesting! I just assumed Darcs development had stopped. Where can I read about this new Darcs 3 theory? I think the next VCS needs to offer a value proposition other than just "better than Git", though. The easiest way to accomplish this would be to piggyback on something popular. For example, if Microsoft started offering a new VCS system built into Visual Studio Code that were enabled for free by default and had awesome built-in integration (VSCode's current VCS integration is nearly useless, IMHO), then I think it could reasonably compete with Git, though it might require competing with Github. (Of course, Microsoft could do this with Github.) Even with this, I don't think a better Darcs would suffice. For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. I think we'd need something like Darcs paired with awesome scalability (Perforce-style central server with partial client-side checkouts) combined with support for arbitrarily large files.

bb88 6y ago
> For example, one thing that Git handles poorly is large files, and it doesn't do well with large repos, either. To be fair though, it's a source tracker which are usually small-ish text files. It's not really meant to be a Digital Asset Manager, say. Git can do a shallow clone as well for very large repos. Much of that deep information becomes probably useless over time, unless you're doing code archaeology.
- atombender 6y ago
  Well, the thread is about what comes after Git. If you ask me how Git could be improved, then what it's "meant" for doesn't matter if there are unsolved use cases. Also, there's no particular reason Git couldn't be modified to work well with large files.
  - bb88 6y ago
    > Git couldn't be modified to work well with large files. Apologies for the late response. Yes. I absolutely agree with that. The trick though is that when changes happen to a large file, what's the best way to do a diff? What if it's bzip2 or encrypted? The other issue is that stagnant large files in your history need to be pruned. I'm not sure how to do that in git right now other than rewrite history.