Hi Dan,
Dan Stromberg wrote:
> <snip>
> The code I'm aiming to replace has had a longstanding problem with SVN
> reliability. ISTR that one of the issues was that a change would be
> checked in, and then checked back out (or merged), and the change just
> made would seem to not be there - for a while, just long enough to
> cause a merge issue in an automatic merge program. Then the next time
> you check, the change is there, as though nothing had ever been wrong.
>
> And I'm now seeing precisely the issue described above not in the new
> program (not yet at least), but in a unit test for the new program.
> The unit test is checking out a file with an integer in it, adding one
> to the integer, checking it back in, checking out the prior rev to a
> different WC, then merging to the latest rev. It's usually fine doing
> this, but once in a while the integer seems to have not been
> incremented.
Subversion uses a simple heuristic to determine if a file has
changed. It is well documented in the source code but perhaps
not so well known:
If the size and time stamp of a file is the same as when checking
out the file it is immediately considered as unchanged. We had a
similar issue where an automatic script failed to commit an updated
file.
This is most easily resolved by adding a small delay between checking
out and performing the modification. We used 2 seconds. You need to
wait long enough for your operating system file time stamp to tick
one step and on Windows this means about 2 seconds to be sure.
There may be some option that can be specified when committing that
forces a deeper check?
Regards
/Daniel Widenfalk
Received on 2010-05-18 10:00:44 CEST