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