4 ms·
Mercurial marks their Largefiles[0] support as a "feature of last resort". IE: enabling this breaks the core concept of what a DVCS is, as you now have a centr
by kyrra 11y ago
Mercurial marks their Largefiles[0] support as a "feature of last resort". IE: enabling this breaks the core concept of what a DVCS is, as you now have a central authority you need to talk with. But at the same time, many people that use Git and HG use it with a central authoritative repo.
[0] https://www.mercurial-scm.org/wiki/LargefilesExtension https://www.mercurial-scm.org/wiki/LargefilesExtension
- novaleaf 11y ago++! When I was in the games industry, it was extremely important to have this feature (and yes, it was a last resort!) This is why, then, we choose Mercurial over Git. Unfortunately there is a lot of wackyness and far too often assets got out of sync. We ended up regressing, and put large assets (artwork) into a subversion repo instead. I wish there was a better option, such as truncating the history of largeFiles, but that seems to break the concept of Git/Mercurial even more than the current "fix"
- kyrra 11y agoHow long ago were you having problems with it? I've heard it's been a lot better in the more recent years.
- novaleaf 11y agoIndeed that was about 5 years ago. The problems generally were around assets getting out of sync, and occasionally corruption when uploading to the large-file storage server. Problems generally occurred when a client timed out in the middle of an upload or download. They were troublesome issues (and silent failures) which made it unusable for production use. Hope they got it fixed, it was a great concept, and well ahead of Git in attempting to solve!