On Fri, Aug 24, 2012 at 09:34:09AM -0500, Archie Cobbs wrote:
> Hi,
>
> I'm following instructions by reporting a bug here first. I'm not
> subscribed to this list and unfortunately don't have time to participate in
> a discussion.
>
> Version:
>
> svn, version 1.6.18 (r1303927)
>
> Problem:
>
> There is a situation where $Id$ substitution is inconsistent. If you svn
> copy and then commit a directory, leaving some files unmodified, after the
> commit all of the files in that directory will have $Id$ showing the
> revision of the commit. But if you blow away the copied directory and then
> check it back out, then the files that were not modified have their
> original, pre-copy revisions showing in the $Id$ strings.
This bug has already been fixed in Subversion 1.7.
I get the following output from your script with a 1.7 client.
+ grep -w Id dir2/file1 dir2/file2
dir2/file1:file1: $Id: file1 1 2012-08-24 15:35:34Z stsp $
dir2/file2:file2: $Id: file2 2 2012-08-24 15:35:34Z stsp $
+ rm -rf dir2
+ svn up dir2
Updating 'dir2':
Restored 'dir2'
Restored 'dir2/file1'
Restored 'dir2/file2'
At revision 2.
+ grep -w Id dir2/file1 dir2/file2
dir2/file1:file1: $Id: file1 1 2012-08-24 15:35:34Z stsp $
dir2/file2:file2: $Id: file2 2 2012-08-24 15:35:34Z stsp $
Note that the last-changed revision means the revision in which
file content last changed. For the purposes of this keyword copy
events are treated as no-ops unless content modification also took
place during the copy.This was most recently discussed in detail
in the following thread: http://svn.haxx.se/dev/archive-2012-07/0010.shtml
(follow links to bug reports and reposonses from there)
Received on 2012-08-24 17:41:13 CEST