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!'.
I hope that's more clear?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Mar 15 22:26:43 2007