Tracking and managing history of a large directory of binary files

[Steve Barnes]

On 18/02/14 19:25, Matt Mackall wrote:
> On Tue, 2014-02-18 at 10:04 +0000, Paul Moore wrote:
>> First of all, it's entirely possible that Mercurial is completely the
>> wrong tool for this, but I don't know of any better one. If what I am
>> doing is totally misguided, can anyone suggest a better solution[1]?
>>
>> I have a large directory (about 3GB) of binary files (mostly small,
>> but some up to 50M in size) that I need to manage across multiple PCs.
> This lays out the memory limitations of Mercurial for single files.
>
> http://mercurial.selenic.com/wiki/HandlingLargeFiles
>
> Shorter version:
>
> 32-bit: ~400MB (Windows) ~1GB Linux
> 64-bit: 2GB
>
> But Mercurial will happily handle 100,000 of those 400MB files, each
> with 100,000 revisions, provided you have the disk space and bandwidth.
>
You could always consider using either of the bigfiles 
<http://mercurial.selenic.com/wiki/BigfilesExtension> or largefiles 
<http://mercurial.selenic.com/wiki/LargefilesExtension> extensions these 
will store a single copy of the revision of the large file at the 
current version on the local hard drive and multiple versions on a 
nominated central server, (in the case of largefiles you will also have 
some copies of other versions in the cache).  This does mean that you 
lose the advantage of the distributed VCS for those files in that you 
need to be connected to the server to switch between revisions where the 
large files change.

The other possibility is that, if your files that you need to manage are 
zip files, (this includes MS .???x formats like .docx), you can use the 
zipdoc <http://mercurial.selenic.com/wiki/ZipdocExtension> extension.

Hope this helps.

Gadget/Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20140218/ed7dc13f/attachment-0002.html>