Question on work-flow for big binary files

[Jesse Glick]

Hans Meine wrote:
> is HgExternalBinaries the same as bigfiles.py?

No, it's an external.py that I wrote from scratch for use on the NetBeans project. Simply provides an encode/decode hook type that communicates with a monotonic binary 
server, i.e. an HTTP server with content like:

http://hg.netbeans.org/binaries/

which also accepts file uploads:

http://hg.netbeans.org/binaries/upload

(The latter is password-protected so that we don't get spam or warez uploaded, but just consists of a single file upload form control and a Submit button.) Since the 
upload script decides on the filename based on content hash (plus sanitized basename), you cannot rewrite history; at worst you can lose an old binary file and not find 
any copy anywhere.

> http://wiki.netbeans.org/HgExternalBinaries talks about HgExternalBinaries 
> being no longer in use for netbeans, but being ditched in favor of a simpler 
> encode/decode hooks solution?

HgExternalBinaries _was_ the encode/decode hooks system. It is correct that we have ceased to use it for NB; while it basically worked, there were some problems listed in 
the Bugs section, mostly due to enc/dec hooks being poorly supported in Hg. We now use

http://wiki.netbeans.org/ExternalBinaries

which uses the exact same server format, but requires manual upload of new binaries from a web browser and does download during a build rather than from inside an Hg 
command. This has proven less error-prone in practice, even if it is not quite as convenient.

If we had TrimmingHistory, there would be no need for tricks like this, I think - we could just check in and push whatever binary files we needed along with everything 
else, and not worry about repository size. Non-DVCS users need not worry since they are not impacted by the size of historical versions of binaries unless and until they 
check out those revisions.