On Jul 11, 2011, at 14:07, Warren Jones wrote: > 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.
Sounds to me like operator error of the following kind: the developer modified the files in the working copy, and also made identical modifications to the corresponding pristine files in .svn/text-base (frequently this happens when using a batch search-replace tool). Because even after the edits the contents of the pristine files match the regular files, "svn st" and "svn di" don't show the changes and they don't get committed. If this is what happened, check out a fresh working copy, manually copy over the changed files, and commit them. And ensure that in the future you do not edit anything in the .svn directories. Some batch search-replace tools let you define directories they're not to touch.
