"Laurent F." <lfournie_at_rockwellcollins.com> wrote on 03/13/2009 12:09:01
PM:
>
> Let us going back to the initial issue, when I was suspecting a bug.
> I looked at the log -v and found that after SVN copy wc -> tags_url,
> it returns on the first record something like:
>
> r41 | laurent ...
> A /tags/releaseX (from /trunk/pkg:40)
> R /tags/releaseX/file1.txt (from /trunk/pkg/file1.txt:24)
> The 'R' stands 'Replace' and A 'Add'
>
> From this log SVN allocates a unique "last_changed Rev" to each node:
> I understand that the root dir (releaseX) get r41 because of the "A"
> but I think the "R" should allocate to file1.txt r24 and not r41 that
> is the origin of the replacement, not the target as currently.
>
> Because users expect replacement origin number, SVN allocation
> algorithm is wrong.
> This is then bug that can be fixed.
>
> People working so well that they always deliver url in trunk won't be
> affected (there is no "R") and for "dirty" developers like us who are
> delivering mixed release, we can count on $Id$ keyword.
>
> The idea is that a "R" does not change the file content so
> last_changed_rev shall not change.
>
> What are your expert viewpoints ?
> I am surprised that this fundamental issue has not been solved
> earlier.
This is the same behavior that occurs if you:
svn cp /trunk/file1.txt /tags/mytag/file.txt
instead of:
svn cp /trunk /tags/mytag.
When copying/replacing individual files, the last changed revision number
for the file is incremented. When copying a parent directory for a tag,
the individual file last changed revision number is not changed.
This really wasn't the behavior I was expecting.
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1318078
Received on 2009-03-13 18:53:47 CET