One of our developers got perplexing results from an SVN commit. As far as I
can tell, this is what happened:
1. Developer checks out trunk of SVN project to working directory.
2. "svn copy" some files from branch into working directory.
3. Edit and modify files copied from branch.
4. "svn commit" in working directory.
After the commit:
1. "svn status" shows the working directory is up to date.
2. "svn diff" shows no modified files in the working directory.
3. Repository contains files copied from branch to trunk.
4. Repository **does not** contain subsequent mods to those files. The
commit somehow missed these changes.
5. File mods are still in the working directory, although not shown by "svn
diff".
6. After file time stamps are updated with "touch", "svn diff" shows
changes.
I'm unable to reproduce this odd state of affairs, but I have the repository
and the developer's working directory to prove that something went wrong with
the commit. I don't know whether it was operator error or a bug in SVN.
Here are some other bits of information that may be relevant:
1. The developer was using SVN v1.6.6 on openSUSE 11.2.
2. The server is v1.6.9, accessed via Apache mod_dav_svn
3. The working directory is on an NFS file system mounted from a NetApp
file server.
4. "svn info" for modified files shows time stamps that may be anomalous:
"Text Last Updated" is about 1 second later than "Last Changed Date". For
example:
Last Changed Date: 2011-03-10 11:02:49 -0800 (Thu, 10 Mar 2011)
Text Last Updated: 2011-03-10 11:02:50 -0800 (Thu, 10 Mar 2011)
5. It's **possible** that there has been some clock skew between the SVN
server, the client workstation and the NetApp file server. I've tried to
reproduce the problem by forcing the workstation clock fast or slow, but
without success.
Thanks in advance to anyone who can explain what happened here!
--
Warren Jones
Fluke Corporation
Software Engineering Support Group
