one byte change to file not detected ?

Ezra.Smith at bentley.com Ezra.Smith at bentley.com
Wed Feb 20 13:42:00 CST 2008


Well, as you've noted, there are cases where mercurial is limited by the
way some filesystems record modification time. If it tried to compensate
by always doing byte-by-byte comparisons of every file to make sure this
did not occur, my multi-gigabyte repository with some thousands of files
would take me an eternity just to run an "hg stat" or "hg commit" on. At
the point where I have to wait two hours to find out what files I've
modified recently, I'd start tracking my modifications with a pen and
paper instead.

As such, I would argue that this is less of a "dumb policy decision to
make [mercurial] benchmark better at the cost of safety," and more of a
feature to make mercurial usable on any large repository.

That being said, if you really have a use case where you're likely to do
multiple commits within the same second, the "sleep 1" wrapper approach
is a good start. It also seems pretty reasonable to add a --force flag
to commit when explicitly naming files to commit, so you can say "Yes, I
know you don't think this file has changed, now check/commit it anyway."

-Ezra

-----Original Message-----
From: mercurial-bounces at selenic.com
[mailto:mercurial-bounces at selenic.com] On Behalf Of BuraphaLinux Server
Sent: Wednesday, February 20, 2008 1:00 PM
To: Matt Nordhoff
Cc: mercurial at selenic.com
Subject: Re: one byte change to file not detected ?

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.)
> --
>
_______________________________________________
Mercurial mailing list
Mercurial at selenic.com
http://selenic.com/mailman/listinfo/mercurial



More information about the Mercurial mailing list