TortoiseHG - Large File Commit (only 40Meg is size)

[Adrian Buehlmann]

On 2011-01-03 06:09, mutface wrote:
> 
> Thanks Adrian. 
> 
> Please understand that laymen like myself will invariably rely on GUIs
> rather than type commands so please forgive me if I may seem stupid. We
> intend to use Hg for predominantly binary files so TortoiseHg is quite
> useful for our purposes. 

Sure. But debugging problems is a different thing.

> As for the question regarding s: drive. 
> 
> The XP box is running on Virtual Machine (Virtual Box) with an Opensuse
> host; the s: drive is a mapped drive which maps to a "Shared Folder" that is
> set up within Virtual Box and maps to something like \\vboxsvr\hg\
> 
> I don't know whether XP running under VirtualBox will cause this problem;
> however I have been able to commit plenty of other files of around 5Meg
> (within the s: drive). 

Just for the record: what versions of VirtualBox and openSUSE are you using?

I recommend not to place Mercurial repositories on such unusual drives.
Use normal local NTFS volumes to commit to.

UNC drives (paths of the form '\\foo\', aka Windows shares) are
problematic anyway, even without exotic parts like VirtualBox and
openSUSE in the loop (see [1]).

Make sure to check repository integrity by using 'hg verify' when moving
away from that drive. I hope you do have backups.

(As a side note: run hg verify when making a backups, so you know that
what you back up is ok. There's hardly anything more frustrating than
noticing your backup doesn't pass verify when you try to use it to
restore a lost repository.)

You probably want to test then if you can read and write big files from
your drive s: without TortoiseHg or Mercurial, since it looks like that
drive (read: the softwares servicing it) on itself might have problems
(I'd try testfiles >100 MB and use some hash software like MD5 to check
integrity of the files before and after each test copy action).

[1] http://mercurial.selenic.com/wiki/HardlinkedClones