One thing which is confusing here is that you're running 'svn list' on
local objects, but the 'list' command always produces a list from the
*repository*, not the working copy. If you want to see the
revision-numbers of your working-copy objects, you should be using
'svn status -v' instead.
That said, take a look at file1.txt in your newly created tag. It's
still the old version, right? Notice that the last-changed-date is
still March 12, not March 30.
I think what's going on is that because file2 and file3 were at
'head', the 'svn cp wc URL' action didn't modify them at all -- they
weren't modified in r20. But because file1 was backdated, the copy
action somehow considered file1 to be a 'changed path' in r20, and
thus shows it as being at r20 in the server -- but I think you'll
discover that /tags/tg/file1.txt_at_20 has exactly the same file contents
as /bug/file1.txt_at_9.
On Wed, Mar 11, 2009 at 5:41 AM, Laurent F.
<lfournie_at_rockwellcollins.com> wrote:
> Hello,
>
> Here a script showing the problem
> ____________________________________
> #!/bin/sh
> target=tg
> svn up bug
> svn list -v bug/*
> svn up -r9 bug/file1.txt
> svn list -v bug/*
> svn copy -m0 bug http://pelinquin/svn/tags/${target}
> svn up ../tags
> svn list -v ../tags/${target}/*
> _____________________________________
> ...and the result:
> ________________________________________
> U bug/file1.txt
> Updated to revision 19.
> 12 laurent 30 mar 11 11:11 file1.txt
> 13 laurent 15 mar 11 11:11 file2.txt
> 14 laurent 30 mar 11 11:13 file3.txt
> U bug/file1.txt
> Updated to revision 9.
> 9 laurent 12 mar 11 10:58 file1.txt
> 13 laurent 15 mar 11 11:11 file2.txt
> 14 laurent 30 mar 11 11:13 file3.txt
>
> Committed revision 20.
> A ../tags/tg
> A ../tags/tg/file2.txt
> A ../tags/tg/file3.txt
> A ../tags/tg/file1.txt
> Updated to revision 20.
> 20 laurent 12 mar 11 11:31 file1.txt
> 13 laurent 15 mar 11 11:11 file2.txt
> 14 laurent 30 mar 11 11:13 file3.txt
> _______________________________________
>
> I would expect that ../tags/tg/file1.txt would be in revision 9
> instead of revision 20
>
> Laurent
>
> On Mar 10, 5:35 pm, "Hyrum K. Wright" <hyrum_wri..._at_mail.utexas.edu>
> wrote:
>> On Mar 10, 2009, at 10:58 AM, Laurent F. wrote:
>>
>>
>>
>> > Hello,
>>
>> > I found a bug in svn development library and it is reproduced with :
>> > - Python svn native swig interface
>> > - Python pysvn module interface
>> > - svn command line
>> > - Tortoise SVN
>>
>> > When I am tagging a project for software delivery I am using 'svn
>> > copy' from my WC to tags/release_X
>>
>> > The original WC has:
>> > - some files as in head revisions
>> > - some files in older revisions (but not modified)
>> > - [and deleted files; not wanted in the deliverable]
>>
>> > If we look at the current revisions of each files of the result tag
>> > tree:
>> > - files copied from head revisions still have the same revision as in
>> > trunk ( ...as expected !) svn display n-1 log rev.
>> > - files copied from older revisions get revisions of the 'copy' call
>> > and not the revision they had in the trunk as I expected !.
>>
>> > First, returning the copy revision for files copied from old revisions
>> > is not the expected revision.
>> > I would rather have the previous one in the log; that is the revision
>> > of the file in the trunk, just before the copy (n-1 in the log).
>> > But Second, why svn applies different rules for those two cases
>> > (always unmodified files) ?
>>
>> > Furthermore, when the trunk change after the delivery, some files
>> > copied from the Head are now referencing older revisions, so revisions
>> > in tags directory are inconsistent;
>> > - some files returns the last log release (log(n))
>> > - other files returns the previous release (log(n-1)
>>
>> > Can you confirm this is a bug ?
>>
>> Can you provide a complete reproduction recipe, preferably in the form
>> of a shell script which demonstrates the bug through the commandline
>> client?
>>
>> Thanks,
>> -Hyrum
>>
>> ------------------------------------------------------http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessag...
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1307428
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1308062
Received on 2009-03-11 15:15:04 CET