4 ms·

> presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). I am not aware of any data loss bugs in tha

by tonfa 13y ago

> presumably because of the wicked data loss bugs they've had (or may still have, I haven't checked this recently). I am not aware of any data loss bugs in that area, or those are related to buggy network filesystems (in which case other VCS would also be affected). The usual issue around shared on disk repo is with permissions (and since a long time mercurial tries to be smart when creating new directory/files in order to propagate the perms regardless of umask).

Silhouette 13y ago
I am not aware of any data loss bugs in that area Cloning a repo hosted on a Linux-based NAS/server to another location on the same NAS/server from a Windows machine tends to set up the clone using hard links rather than a true copy by default. That in itself is not a problem, but unfortunately the Windows hg client doesn't seem to detect this situation reliably (or at least didn't last time I checked, which is a few months ago now). That means if you then commit changes, you can be unintentionally affecting the common linked files rather than separating them on demand first. The same was true for TortoiseHg the last time I checked, this again being a few months ago. This is a particularly wicked bug because it means even if you've cloned a repo elsewhere on your network drive with the intent of keeping an independent backup of everything, both versions will be corrupted, and the first you're likely to notice is if you run an hg verify and find the index data for your original repo (which as far you know is untouched) suddenly has errors in it. Incidentally, if you are using this sort of scenario for whatever reason, there is an option you can set at cloning time to force a full copy to be made. I've also heard of problems with file locking being unreliable if you're using NFS to access the server, but the only cases I've seen were set up a different way so I can't offer anything more than a general warning in that case.
- garenp 13y ago
  If you're using NFS, CIFS or smbfs to host or synchronize repo data, You're Gonna Have A Bad Time (YGHABT?) regardless of which VCS you're using - it's only a matter of time.

by tonfa 13y ago

Silhouette 13y ago

I am not aware of any data loss bugs in that area Cloning a repo hosted on a Linux-based NAS/server to another location on the same NAS/server from a Windows machine tends to set up the clone using hard links rather than a true copy by default. That in itself is not a problem, but unfortunately the Windows hg client doesn't seem to detect this situation reliably (or at least didn't last time I checked, which is a few months ago now). That means if you then commit changes, you can be unintentionally affecting the common linked files rather than separating them on demand first. The same was true for TortoiseHg the last time I checked, this again being a few months ago. This is a particularly wicked bug because it means even if you've cloned a repo elsewhere on your network drive with the intent of keeping an independent backup of everything, both versions will be corrupted, and the first you're likely to notice is if you run an hg verify and find the index data for your original repo (which as far you know is untouched) suddenly has errors in it. Incidentally, if you are using this sort of scenario for whatever reason, there is an option you can set at cloning time to force a full copy to be made. I've also heard of problems with file locking being unreliable if you're using NFS to access the server, but the only cases I've seen were set up a different way so I can't offer anything more than a general warning in that case.

garenp 13y ago
If you're using NFS, CIFS or smbfs to host or synchronize repo data, You're Gonna Have A Bad Time (YGHABT?) regardless of which VCS you're using - it's only a matter of time.