You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Satya Mishra <sa...@gmail.com> on 2019/03/05 18:23:32 UTC
Why does svn up give me a different file than in the repo
Hi,
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.
> rm -f projfile
> svn up projfile
Updating 'projfile':
Restored 'projfile'
At revision 6878.
> sha1sum projfile
c58a4e654e2e8ac565e9705a7f83901a3ea7e321 projfile
> svn info projfile
Path: projfile
Name: projfile
Working Copy Root Path: ~/proj
URL: svn://repohost/proj/trunk/projfile
Relative URL: ^/proj/trunk/projfile
Repository Root: svn://repohost
Repository UUID: .....
Revision: 6878
Node Kind: file
Schedule: normal
Last Changed Author: satya
Last Changed Rev: 5734
Last Changed Date: 2018-03-27 12:03:21 -0700 (Tue, 27 Mar 2018)
Text Last Updated: 2019-03-05 10:03:46 -0800 (Tue, 05 Mar 2019)
Checksum: 6c0ff2498b56833e603908a66a284351ad0ec7dc
Fwd: Why does svn up give me a different file than in the repo
Posted by Satya Mishra <sa...@gmail.com>.
Thanks a lot for the suggestion. This is a binary file. I double checked
the properties (output below signature)
I also noticed another thread titled " E155011 + E160013: how to clear this
mess? " which seems to be a similar issue. But svn up --set-depth empty,
which worked for the other user, didn't fix it for me.
Regards,
Satya
> svn pl projfile
Properties on 'projfile':
svn:mime-type
svn:needs-lock
> svn pg svn:mime-type projfile
application/octet-stream
On Tue, Mar 5, 2019 at 12:42 PM Eric Johnson <er...@tibco.com> wrote:
> Possibly a line-ending conversion?
>
>
> http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
>
> Check to see if the svn:eol-style property is set.
>
> Eric
>
> On Tue, Mar 5, 2019 at 10:34 AM Satya Mishra <sa...@gmail.com>
> wrote:
>
>> Hi,
>>
>> 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.
>>
>> > rm -f projfile
>> > svn up projfile
>> Updating 'projfile':
>> Restored 'projfile'
>> At revision 6878.
>> > sha1sum projfile
>> c58a4e654e2e8ac565e9705a7f83901a3ea7e321 projfile
>> > svn info projfile
>> Path: projfile
>> Name: projfile
>> Working Copy Root Path: ~/proj
>> URL: svn://repohost/proj/trunk/projfile
>> Relative URL: ^/proj/trunk/projfile
>> Repository Root: svn://repohost
>> Repository UUID: .....
>> Revision: 6878
>> Node Kind: file
>> Schedule: normal
>> Last Changed Author: satya
>> Last Changed Rev: 5734
>> Last Changed Date: 2018-03-27 12:03:21 -0700 (Tue, 27 Mar 2018)
>> Text Last Updated: 2019-03-05 10:03:46 -0800 (Tue, 05 Mar 2019)
>> Checksum: 6c0ff2498b56833e603908a66a284351ad0ec7dc
>>
>>
>>
>>
Re: Why does svn up give me a different file than in the repo
Posted by Eric Johnson <er...@tibco.com>.
Possibly a line-ending conversion?
http://svnbook.red-bean.com/nightly/en/svn.advanced.props.file-portability.html#svn.advanced.props.special.eol-style
Check to see if the svn:eol-style property is set.
Eric
On Tue, Mar 5, 2019 at 10:34 AM Satya Mishra <sa...@gmail.com> wrote:
> Hi,
>
> 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.
>
> > rm -f projfile
> > svn up projfile
> Updating 'projfile':
> Restored 'projfile'
> At revision 6878.
> > sha1sum projfile
> c58a4e654e2e8ac565e9705a7f83901a3ea7e321 projfile
> > svn info projfile
> Path: projfile
> Name: projfile
> Working Copy Root Path: ~/proj
> URL: svn://repohost/proj/trunk/projfile
> Relative URL: ^/proj/trunk/projfile
> Repository Root: svn://repohost
> Repository UUID: .....
> Revision: 6878
> Node Kind: file
> Schedule: normal
> Last Changed Author: satya
> Last Changed Rev: 5734
> Last Changed Date: 2018-03-27 12:03:21 -0700 (Tue, 27 Mar 2018)
> Text Last Updated: 2019-03-05 10:03:46 -0800 (Tue, 05 Mar 2019)
> Checksum: 6c0ff2498b56833e603908a66a284351ad0ec7dc
>
>
>
>
Re: Why does svn up give me a different file than in the repo
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2019-03-07 17:50:26 +0100, Branko Čibej wrote:
> On 07.03.2019 17:36, Vincent Lefevre wrote:
> > On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
> >> 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.
> > Would it be a good idea to protect the .svn directory by default?
> > I mean that Subversion would unprotect it before an operation and
> > protect it again just after.
>
> How would you do that, realistically? I can't think of any way other
> than changing permissions on all files within that directory.
Unsetting the 'r' permission on the .svn directory should be
sufficient: recursive operations would not be able to open this
directory for reading.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Why does svn up give me a different file than in the repo
Posted by Branko Čibej <br...@apache.org>.
On 07.03.2019 17:36, Vincent Lefevre wrote:
> On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
>> 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.
> Would it be a good idea to protect the .svn directory by default?
> I mean that Subversion would unprotect it before an operation and
> protect it again just after.
How would you do that, realistically? I can't think of any way other
than changing permissions on all files within that directory.
-- Brane
Re: Why does svn up give me a different file than in the repo
Posted by Vincent Lefevre <vi...@vinc17.net>.
On 2019-03-07 05:26:48 -0600, Ryan Schmidt wrote:
> 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.
Would it be a good idea to protect the .svn directory by default?
I mean that Subversion would unprotect it before an operation and
protect it again just after.
--
Vincent Lefèvre <vi...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
Re: Why does svn up give me a different file than in the repo
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.
Re: Why does svn up give me a different file than in the repo
Posted by Satya Mishra <sa...@gmail.com>.
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 <su...@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.
>
>
Re: Why does svn up give me a different file than in the repo
Posted by Ryan Schmidt <su...@ryandesign.com>.
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.