On Mar 6, 2019, at 09:44, Satya Mishra wrote:
> On Tue, Mar 5, 2019 at 11:39 PM Ryan Schmidt 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.
>
> 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.
I had this problem once when I ran a recursive sed command over my working
copy, not considering that it would modify the contents of the .svn directory
too.
