one byte change to file not detected ?

[Talden]

Or include a path/pattern list mechanism that indicates requiring a
deep-scan... For most users this is empty, for those with special
needs they'll note the few files that might exhibit this problem.

--
Talden

On Thu, Feb 21, 2008 at 8:42 AM,  <Ezra.Smith at bentley.com> wrote:
> 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
>
>  _______________________________________________
>  Mercurial mailing list
>  Mercurial at selenic.com
>  http://selenic.com/mailman/listinfo/mercurial
>