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 <jcor...@gmail.com>
To: webster.br...@rogers.com
Cc: "users@subversion.apache.org" <users@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.br...@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
