Indeed the pristines had been modified. I didn't directly touch them myself. I only worked on the files in the working copy.
This is clearly the incorrect file. > sha1sum .svn/pristine/6c/6c0ff2498b56833e603908a66a284351ad0ec7dc.svn-base c58a4e654e2e8ac565e9705a7f83901a3ea7e321 .svn/pristine/6c/6c0ff2498b56833e603908a66a284351ad0ec7dc.svn-base Thank you very much for the help. It's possible that I might have accidentally run hardlink on this working directory, though I don't remember doing it. If I ever encounter the situation again, I will debug further. Regards, Satya On Tue, Mar 5, 2019 at 11:39 PM Ryan Schmidt <subversion-2...@ryandesign.com> wrote: > On Mar 5, 2019, at 12:23, Satya Mishra wrote: > > > I recently encountered a strange problem while trying to revert a failed > experiment. svn revert apparently succeeded, but kept giving me the > unreverted files. Example shell output showing the problem is below. The > sha1sum of the file doesn't match the sha1sum from repo in this working > copy. But it does in a freshly checked out working copy. I am using > Subversion 1.10.3 on CentOS 7. I'll greatly appreciate any insight into why > this might happen. > > Is it possible that your "failed experiment" modified the pristine files > in .svn/pristine? When you "svn revert" a file, all that Subversion does is > to copy the corresponding file from .svn/pristine. Subversion intends that > the files in .svn/pristine are pristine -- unchanged -- but if you've > modified them, then they won't be. Subversion assumes that nothing other > than Subversion will modify the contents of the .svn directory. > > On the other hand, if you "svn checkout" a new working copy, the pristines > (and the rest of the contents of the .svn directory) don't yet exist, so > Subversion sets up the .svn directory and downloads the pristines from the > repository. > >