>>>> email@example.com 02/17/06 8:19 am >>>
>> Julian Foad <firstname.lastname@example.org> writes:
>>>>>Shouldn't it notice that the file size and date are not as
>>>>>and return a "modified" status immediately?
>>>>Do we record the unmodified working file size for translated files
>>>>.svn/entries? If so, then we could detect modified-ness this way.
>>>We don't currently store any size information there. However, I'm
>>>thinking it's not so easy. (It would have been done if it were.)
>>>Even if you modify the file by changing some keyword value or EOL
>>>style, as long as it translates back to the same pristine text we
>>>report it as unchanged. Therefore the size doesn't tell us
>> Not so fast...
>> A size check can tell you if something is definitely modified.
>> only if the size comes back the same as what you recorded before
>> you have to do further investigation. The algorithm is:
>> if (timestamp is same)
>> return not_modified;
>> else if (size differs)
>> return modified;
>This is indeed the algorithm that we use, and it's fine for
>a file without keyword or EOL translations matches its text base.
>It doesn't work for determining whether a translated working file
(that is, one
>in which keyword expansions or EOL conversions are in effect) still
>pristine copy. If such a working file's time stamp and size have both
>since the last time we looked at it, then certainly it's been changed,
>don't know whether it will match its text base. It might, so we have
>it and see.
>That's the case I meant by "the size doesn't tell us anything", I
>in all cases.
>David James wrote:
>> So if the timestamp is the same, but the size differs, we return
>> modified"? That seems strange to me.
>Yes, but it's quite reasonable in practice. For one thing, it is only
>unusual situations that a file is modified but its time stamp is kept
Not so quite unusual. I've got through a lot of problems on Windows
operation on a working copy are realised with batch files. In my
the modification of a file (that do not change it's size) was done
immediately after a checkout.
The working copy was not seeing the modification. I've got to generate
a time gap over few seconds
between my checkout and my modification if I wanted the working copy to
the file as modified.
> For another thing, if a file is modified but its time stamp is not,
>doesn't necessarily change, and we don't intend to detect that case,
>not detecting cases when the size has changed is only worse in
>That said, if we can read both time stamp and size together as Karl
>then we certainly should do better by checking them both before making
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
« Le présent courriel peut contenir des renseignements confidentiels et ne s'adresse qu'au destinataire dont le nom apparaît ci-dessus. Si ce courriel vous est parvenu par mégarde, veuillez le supprimer et nous en aviser aussitôt. Merci. »
Received on Fri Feb 17 14:47:36 2006