[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore

From: <webster.brent_at_rogers.com>
Date: Thu, 10 Mar 2016 15:19:28 +0000 (UTC)

Johan, thanks for the insights/efforts. Sorry about html --- damm Yahoo mail.
It is possible that these files were chmod'd but I can't confirm now.  It is good to know that changing file permissions won't be detected by a "svn status" but will get reverted.  I've got 100+ exClearcase designers that love to point out every quirk in SVN.
I definitely would be preferable if "svn status" and "svn revert" use the same concept of changes.
Again, thanks for the help. ---- Brent

      From: Johan Corveleyn <jcorvel_at_gmail.com>
 To: webster.brent_at_rogers.com
Cc: "users_at_subversion.apache.org" <users_at_subversion.apache.org>
 Sent: Wednesday, March 9, 2016 7:10 PM
 Subject: Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore
   
[ Please, if possible, use plain-text on this mailing list, and use
bottom-posting (putting your reply at the bottom, or inline to the
thing you're replying to). More below ... ]

On Wed, Mar 9, 2016 at 3:08 PM,  <webster.brent_at_rogers.com> wrote:
> These files were never changed in the first place, that's the weird part.
> We aren't using any local locks in the repo.

Okay, so definitely a "non-content-changing" revert then. So we're
talking about needless notifications by revert, possibly scaring
users.

I've quickly tried to reproduce it, based on Bert's explanation of
read-onlyness changes. No need for locks or the svn:needs-lock
property. Just make a file read-only, and run a recursive revert. The
file is made writable again, and revert notifies:

[[[
C:\Temp\svntest>svn --version -q
1.9.3-SlikSvn

C:\Temp\svntest>svnadmin create repos

C:\Temp\svntest>svn co file:///c:/Temp/svntest/repos wc
Checked out revision 0.

C:\Temp\svntest>cd wc

C:\Temp\svntest\wc>echo This is file 1 > file1.txt

C:\Temp\svntest\wc>svn add *.txt
A        file1.txt

C:\Temp\svntest\wc>svn ci -mm
Adding        file1.txt
Transmitting file data ..done
Committing transaction...
Committed revision 1.

C:\Temp\svntest\wc>attrib +R file1.txt  ### (making read-only)

C:\Temp\svntest\wc>svn st

C:\Temp\svntest\wc>svn revert -R .
Reverted 'file1.txt'
]]]

Is this similar to what could have happened, Brent? I'm assuming it's
not Windows-specific, because you reported the problem for a 1.8.14
svn client on Centos6.5 Linux. Maybe other variants of changes in
permissions, executability or file ownership also give the same
behaviour.

I agree this is an issue, but I'm not sure if there is only one issue
or two :-).

1) Is it OK for revert to change file metadata? Is that intended
behaviour? Maybe it's OK for revert to change file metadata if the
file also has content-changes that need to be reverted, but not if the
file only has metadata-changes?

2) If we revert metadata-only-changed files, should revert notify
about this? If it notifies for a metadata-only change, maybe the
notification should indicate this?

Hmmmm

-- 
Johan
  
Received on 2016-03-10 16:19:40 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.