<div dir="ltr">Hi,<div><br></div><div>For several years I have pondered about using the largefiles extension or not, and now that I' forced to look at the problem again by a practical problem (large binary assets) I see two fundamental problems for its usage:</div><div><br></div><div><br></div><div>1) It is not transparent to the user: It requires a static limit, that in my opinion should be dynamic (i.e. large files could be cached)... file revisions not handled by binary diffing, and requires manual file extension configuration (when IMHO, this could be done by detecting binary content as a sensible default, then let the user specify other files).</div><div><br></div><div>2) It is not enabled by default: This leads to services like Bitbucket not supporting it, and being disregarded as a real problem. Yes, it is said it breaks the D in DVCS, but I think this would not be the case if the default behavior was to download all binary assets. if binary files revisions were handled by binary diffing, this would probably be less of a problem, and if when cloning Mercurial just suggested to download the latest file and point to a cached resource instead of reconstructing history from a separate store.</div><div><br></div><div>Large file handling is a fundamental problem in DVCS technology, and I hereby propose that Mercurial exploits the solution it already has, and stops seeing large files as a last resort and more as a feature.<br></div><div><br></div><div>Sure, there are major technical obstacles to this... but imagine... if Mercurial *just worked* for binary/large files.</div><div><br></div><div>Thanks,</div><div><br></div><div>David</div></div>