subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Satya Mishra <>
Subject Re: Why does svn up give me a different file than in the repo
Date Wed, 06 Mar 2019 15:44:14 GMT
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

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


On Tue, Mar 5, 2019 at 11:39 PM Ryan Schmidt <>

> 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.

View raw message