> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: woensdag 11 mei 2011 3:47
> To: Subversion Development
> Cc: Bert Huijben
> Subject: 'svn revert -R .' claiming false reversions and doing nothing
>
> I noticed the following tonight:
>
> $ svn st
> M subversion/libsvn_ra_neon/fetch.c
> $ svn revert -R .
> Reverted 'win-tests.py'
> Reverted 'notes/merge-tracking/func-spec.html'
> Reverted 'notes/merge-tracking/requirements.html'
> Reverted 'notes/merge-tracking/design.html'
> Reverted 'notes/repos_upgrade_HOWTO'
> Reverted 'notes/api-errata/1.7/ra001.txt'
> Reverted 'notes/api-errata/1.7/wc001.txt'
> Reverted 'notes/api-errata/1.7/wc002.txt'
> Reverted 'notes/api-errata/1.7/wc003.txt'
> Reverted 'notes/api-errata/1.7/wc004.txt'
> Reverted 'notes/api-errata/1.7/wc005.txt'
> Reverted 'notes/api-errata/1.7/wc006.txt'
> Reverted 'notes/api-errata/1.7/wc007.txt'
> Reverted 'notes/variance-adjusted-patching.html'
> Reverted 'README'
> Reverted 'subversion/libsvn_ra_neon/fetch.c'
> Reverted 'contrib/client-side/svn_all_diffs.pl'
> Reverted 'contrib/client-side/svn-merge-vendor.py'
> Reverted 'contrib/client-side/svn_load_dirs/svn_load_dirs.pl.in'
> Reverted 'contrib/client-side/svnmerge/svnmerge.sh'
> Reverted 'contrib/client-side/svnmerge/svnmerge-migrate-history-
> remotely.py'
> Reverted 'contrib/client-side/svnmerge/svnmerge-migrate-history.py'
> Reverted 'contrib/client-side/svnmerge/svnmerge.py'
> Reverted 'contrib/client-side/emacs/psvn.el'
> Reverted 'contrib/client-side/diff-wrap.sh'
> Reverted 'contrib/client-side/svn_export_empty_files.py'
> Reverted 'contrib/client-side/asvn'
> Reverted 'contrib/client-side/svn_apply_autoprops.py'
> Reverted 'contrib/cgi/mirror_dir_through_svn.cgi'
> Reverted 'contrib/hook-scripts/case-insensitive.py'
> Reverted 'contrib/hook-scripts/detect-merge-conflicts.sh'
> Reverted 'contrib/hook-scripts/commit-email.pl.in'
> Reverted 'contrib/hook-scripts/svn-keyword-check.pl'
> Reverted 'contrib/server-side/fsfsfixer/fixer/fix-rev.py'
> Reverted 'contrib/server-side/add-needs-lock.py'
> Reverted 'contrib/server-side/svn-fast-backup'
> Reverted 'tools/backup/hot-backup.py.in'
> Reverted 'tools/hook-scripts/svn2feed.py'
> Reverted 'tools/hook-scripts/commit-access-control.pl.in'
> Reverted 'tools/hook-scripts/svnperms.py'
> Reverted 'tools/hook-scripts/mailer/mailer.py'
> Reverted 'tools/hook-scripts/mailer/tests/mailer.conf'
> Reverted 'tools/hook-scripts/mailer/mailer.conf.example'
> Reverted 'tools/hook-scripts/svnperms.conf.example'
> Reverted 'tools/hook-scripts/commit-access-control.cfg.example'
> Reverted 'tools/server-side/fsfs-reshard.py'
> Reverted 'tools/po/l10n-report.py'
> Reverted 'tools/dev/which-error.py'
> Reverted 'tools/dev/gen_junit_report.py'
> Reverted 'INSTALL'
> Reverted 'packages/windows-innosetup/W32notes.txt'
> Reverted 'packages/windows-innosetup/Readme.txt'
> $ svn revert -R .
> Reverted 'win-tests.py'
> Reverted 'notes/merge-tracking/func-spec.html'
> Reverted 'notes/merge-tracking/requirements.html'
> [...]
> ### SAME LIST OF FILES
>
> I *think* the one thing that's interesting about these files is that they
> have svn:keywords set on them. At any rate, Subversion now seems to think
> that they are in need of byte-for-byte comparison all the time. I see the
> code passing through svn_wc__internal_file_modified_p(), which Bert
> seems to
> have made a major change to recently (r1101473). I haven't time to debug at
> the moment, but wanted to let folks know.
Strange...
Revert is one of the few places which checks if files are changed by normalizing to the working copy format (translated) instead of to the repository normal format.
But that shouldn't show up on that many files.
Ok r1101726 explains what I did wrong.
I'm not 100% sure if they really need the byte for byte comparison...
But at least we shouldn't accept a recorded match as ok, while we would require a byte for byte translated match if we don't have a recorded value.
So we should either keep this behavior, or accept that a normalized format compare is ok.
Accepting an old normalized format compare result, but not accepting a current normalized compare result is just weird behavior. (But this is what it did before r1101473)
Bert
Received on 2011-05-11 04:08:41 CEST