Actually, I would have thought that the algorithm detecting modified
files would be different between inspecting working-copy files in view
of a commit and detecting an abandoned propedit. The tradeoff between
accuracy and speed mentioned in the discussions cited by Ryan will not
be the same for the propedit for the following reasons:
- there is exactly one file to be checked per transaction
- that file will be tiny in the vast majority of cases
- the original content of the file is known to propedit and need not be
read from a file
- the probability of the file being changed on disk is very close to one
(how often do you cancel a propedit?)
- the chances of the file being younger than one second are big as it is
a temporary file created just for this transaction
As a result, the current algorithm has a much higher chance of failing
in this context compared to checks on working-copy files. And a correct
algorithm would entail a negligible performance hit. Most notably it
would be faster than the currently necessary workarounds (combined
propdel and propset or one second of sleep). I would think that just
reading the file and running a byte-wise comparison for changes would
probably the most efficient algorithm both in terms of execution speed
and coding.
Just my €0.02.
Ryan Schmidt wrote :
>
> On Mar 12, 2006, at 05:37, Kalin KOZHUHAROV wrote:
>
>>> The fact that Subversion doesn't notice differences if the modification
>>> occurs within the same second has come up on the list before. For
>>> example:
>>>
>>> http://svn.haxx.se/users/archive-2005-03/0783.shtml
>>>
>>> I searched http://svn.haxx.se/users for "one second"; there were other
>>> results.
>>
>>
>> OK, I kind of missed most of this thread, but this behavior is a bug,
>> right?
>>
>>>>> svn propedit myproperty --editor-cmd "sed -i -e 's/foo/bar/g'" mypath
>>>>> then svn will respond: "No changes to property 'myproperty' on
>>>>> 'mypath'".
>>>>
>>
>> I couldn't find any related issues in the issue tracker, are there any?
>> Or why is it a WONTFIX bug?
>
>
> There was some other discussion about this on the users list in 2005
> which I cannot find at the moment; the proper search terms elude me. I
> believe it boiled down to the only way to avoid this problem would be
> for Subversion to actually check the files' entire contents every
> time, which would be way too slow to be usable, and so this compromise
> was reached that the mtime and/or file size are checked first.
> According to this developer discussion from last month...
>
> http://svn.haxx.se/dev/archive-2006-02/1034.shtml
>
> ...the algorithm currently is:
>
> if (timestamp is same)
> return not_modified;
> else if (size differs)
> return modified;
> else
> go_into_expensive_further_investigation();
>
> See also other parts of that discussion, like:
>
> http://svn.haxx.se/dev/archive-2006-02/1092.shtml
>
>
> I did also find this developer discussion from late 2002 suggesting
> that the current behavior was fine but just needed to be documented
> better:
>
> http://svn.haxx.se/dev/archive-2002-11/1065.shtml
>
>
>
>> So far the ugly workaround seems:
>>
>>>> using a combination of propdel and propset now. Quite ugly but it
>>>> works.
>>>
>
> Not sure why that works... the workaround would seem to be for your
> script to sleep for 1 second between operations to ensure that the
> timestamp is different.
Neither propdel nor proset need to check a file for changes and
therefore they succeed. Sleeping for a second works, too, but is sloooow
if the script operates on many files.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Mar 13 11:28:09 2006