> -----Original Message-----
> From: philip_at_tigris.org [mailto:philip_at_tigris.org]
> Sent: maandag 11 maart 2013 18:17
> To: issues_at_subversion.tigris.org
> Subject: [Issue 4334] New - move-update not setting last_mod_time in
> destination
>
> http://subversion.tigris.org/issues/show_bug.cgi?id=4334
> Issue #|4334
> Summary|move-update not setting last_mod_time in
destination
> Component|subversion
> Version|trunk
> Platform|All
> URL|
> OS/Version|All
> Status|NEW
> Status whiteboard|
> Keywords|
> Resolution|
> Issue type|DEFECT
> Priority|P3
> Subcomponent|libsvn_wc
> Assigned to|issues_at_subversion
> Reported by|philip
>
>
>
>
>
>
> ------- Additional comments from philip_at_tigris.org Mon Mar 11 10:16:30
-0700
> 2013 -------
> svnadmin create repo
> svn import -mm repo/format file://`pwd`/repo/A/f
> svnmucc -mm put repo/README.txt file://`pwd`/repo/A/f
> svn co file://`pwd`/repo wc
> svn mv wc/A wc/A2
>
> A/f and A2/f both have last_mod_time set, that's OK. (Perhaps we should
> remove
> last_mod_time from the deleted A/f but that's not the bug here.)
>
> svn up --accept postpone -r1 wc
>
> A/f has lost_mod_time cleared, thats OK. A2/f unchanged and still has
> last_mod_time.
A/f should be shadowed with a base-delete layer that doesn't have mod_time
and translated size set?
(And should still have it at its original original op-depth)
The move back code relies on the node keeping its original values, and even
if just the size is still valid for some target it can help as performance
optimization.
>
> svn resolve --accept mc wc/A
>
> A2/f has last_mod_time cleared, that's a bug. It means the client will
have to
> do a full-text comparison to detect differences.
If the properties and/or checksum changed this is safer than keeping the old
value. It will slow us down a bit, but the behavior is not broken.
The next svn_wc_text_modified_p() call when we have a write lock should fix
it. (That is also a quick fix you might be able to apply)
It is safer this way, then to always keep it.
But of course it would be nicer if we can just fix it ;-)
Bert
Received on 2013-03-11 18:40:49 CET