subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ryan Schmidt <>
Subject Re: Why does svn up give me a different file than in the repo
Date Thu, 07 Mar 2019 11:26:48 GMT

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. 
View raw message