one byte change to file not detected ?

[BuraphaLinux Server]

Clearly mercurial cares more about speed than safety.

Yeah, I can patch it but then I have to rehack it every time they
release since clearly this is some dumb policy decision to make their
stuff benchmark better at the cost of safety.

If any of the developers is reading this, please consider a switch
like --paranoid for people like me that choose to be safe and are
willing to go slowly.  No amount of sorry is every going to make up
for data loss....


On 2/21/08, Matt Nordhoff <mnordhoff at mattnordhoff.com> wrote:
> BuraphaLinux Server wrote:
> > The attached script shows that on my system, mercurial cannot detect a
> > 1 byte difference in a file.  Sometimes the script works, but most of
> > the time it fails.  I wonder if mercurial is using the file size and
> > time to skip doing a real byte-by-byte comparison, and my clock
> > granularity is not fine enough?  I am willing to pay the penalty of
> > the slowdown if I can force a byte-by-byte comparison of every file
> > every time, but I don't know how to turn that on.
> >
> > If I add a line 'sleep 1' after the first commit, then the script
> > correctly works and I get 2 revisions instead of the dreaded 'nothing
> > changed' message.
> >
> > Is this a known issue?  Should I make a wrapper for hg that just
> > always does a sleep after each operation?
> >
> > I ran the tests with this:
> >
> > for x in $(seq 1 10); do ./PANIC; done
>
> Exactly. Hg doesn't do a byte-by-byte comparison if the size and
> modification time haven't changed. I don't believe there's a way to
> change that ATM. It would probably be easy to hack that bit out of the code.
>
> (I didn't read the script.)
> --
>