Philip Martin wrote:
> I think svn_wc__maybe_set_read_only can change the timestamp (if it
> does a copy-move-delete) but you have put it just after the code that
> records the timestamp, that's not good. I wonder if any of the other
> uses of svn_wc__maybe_set_read_only have the same problem?
It is called in 5 other places that I found:
1. subversion\libsvn_wc\adm_crawler.c:restore_file - calls it and then
fixes up the executable flag, conflicts and timestamps so it looks fine
(as long as setting permissions and timestamps on files can be done when
it is readonly -- it's all considered file metadata I suppose?)
2. subversion\libsvn_wc\log.c:file_xfer_under_path - calls it and then
fixes up the executable bit so it looks fine (timestamps are ok to be
changed here, correct?)
3. subversion\libsvn_wc\log.c:install_committed_file - calls it and then
fixes up the executable flag. It looks like this case should be
following what the executable flag change does and set the did_set flag?
4. subversion\libsvn_wc\log.c:log_do_file_maybe_readonly - calls it...I
don't know much about this though. Is it just replaying log files which
means it should be fine, I think?
5. subversion\libsvn_wc\merge.c:svn_wc_merge - calls it, which should be
fine even if it changes timestamps, right?
For fixing revert, if I put the call to svn_wc__maybe_set_read_only
before the svn_wc__maybe_set_executable call in
adm_ops.c:revert_admin_things, then it will correctly revert all cases I
tried except where the needs-lock property is dropped and then reverted.
In that case, even if I add the needs-lock to the magic property check,
svn_wc_get_prop_diffs does not return a diff for the dropped needs-lock
property and so it drops through without touching the working file at
all. It seems like this means the executable flag has the same problem
-- if the property and file permission is dropped and then reverted, the
flag is not correctly put back (unless it is inherited from the base
copy or something?).
Any ideas on how to handle that situation? It's probably not a common
use-case since the needs-lock property is likely to be a pretty
permanent thing, but still...
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Apr 28 21:45:55 2005