Re: WC modification detection is reading whole files

kfogel@collab.net writes:

> David James <djames@collab.net> writes:
>> So if the timestamp is the same, but the size differs, we return "not
>> modified"? That seems strange to me.
>
> I may have put them in the wrong order. (Actually, I think we may
> have implemented it that way first, then realized that we could get
> the size at the same time as we get the timestamp, so we might as well
> check size first.)
>
> But now that I go look at the code, things are even weirder than that.
> The algorithm is implemented clearly only in libsvn_wc/props.c -- and
> it duplicates the stat() calls, sadly. Comments there confirm this
> was not done unknowingly, at least.

I added those comments to describe the behaviour, but I didn't write
the code.

> What about text bases? Are we really ignoring the filesizes there
> completely? Oh... no, I think I see: follow the logic in
> svn_wc_text_modified_p2() and you'll see what's going on. Again, we
> end up duplicating stat() calls. And we check the timestamp first,
> but only if no force_comparison flag was passed.
>
> This is somewhat dissatisfying. If we had a function that would use
> one stat() call to get both a file's size and its modtime, then we
> could do all this more efficiently. It seems we decided to let API
> cleanliness govern code flow.
>
> Hmmm. I'm not sure I want to do anything about this (other bugs to
> fix), but then again I'm not sure I want to *not* do anything about it
> either. Thoughts?

A lot of the above is discussed in notes/wc-improvements (that file is
a little out-of-date since some of the property handling has already
been implemented).

I think caching the size of the unmodified working file would be a
good thing. However if we stop doing a translation and byte-by-byte
comparison we need to consider what happens when "modifications"
disapear, e.g if I modify an expanded keyword and the file shows up as
modified then what, if anything, gets committed if the file has no
modifications when converted back to repository form?

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org