> David James <email@example.com> 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
> 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
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?
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Feb 17 16:24:48 2006