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)
