Erik Huelsmann writes:
> On 3/15/07, Peter Lundblad <plundblad@google.com> wrote:
> > Erik Huelsmann writes:
> > > >Also, why is the difference between unknown value and "value not recorded
> > > >because the file is modified" important. I'd say these two boils down to the
> > > >same. If the file is modified compared to the base, you catually *don't know*
> > > >the real value. I'd say we need to distinguish between present and not
> > > >present. If present, use it, else fall back on other means. If we know the
> > > >value and know we can use it, write it, else make it not present.
> > >
> > > Well, the difference between present and not-present or
> > > known-modified/present/not-present is that in the case of
> > > known-modified the actual size and the value which would have been in
> > > the entries file may be equal. So, I think I improved the detection
> > > heuristic though I may have 'abused' one of the fields for it. I think
> > > it would be a shame to discard the fact that a file was changed and
> > > needs close inspection.
> >
> > I'm sorry, but I don't understand the above (maybe becaue it is still too
> > early;). Can yoiu give an example clarifying?
>
> Sure:
>
> When I update, libsvn_wc determines whether or not a file has been
> locally modified in order to choose between merge and simple
> replacement. If it finds differences with the base version, it decides
> on merging. However when that happens, we don't have the actual size
> of the file available to set in the entries file.
>
> If we then set the value to 'not available', the only remaining way to
> determine whether a file has changed is by its timestamp. We know
> however that the file should explicitly be checked for changes since
> the last time we saw the file, it had been changed. I'm using the
> working-size field for this, by setting it to a value which means 'I
> don't know the actual working-size to compare with, but last time I
> checked the file was changed. You should check again!'.
>
But in that case we clear the timestamp as well which should force
a comparison, right? So:
- If we have neither text-time nor working-size or any of the differ, force a
byte-by-byte comparison.
- If we have text-time but not working-size, check text-time. If that's
different, fall back on byte-by-byte. this is to not bog down when we do status
on a pre 1.5 working copy that wasn't updated/cleanuped etc.
Does the above make sense?
Thanks,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 23:47:06 2007