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-2019_at_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.
>
>
Received on 2019-03-06 16:44:36 CET