I don't think there's a solution here.
If I run "svn copy trunkURL tagURL", only *one* new directory node is
created -- the tag directory. All of the children are 'shared' nodes,
still unchanged, and referred to by both the trunk and tag
directories. That's why 'svn ls' still shows the children as being at
the same revisions.
But when one of the children isn't at the same HEAD revision as the
parent, then your 'svn cp wc tagURL' causes a *separate* copy to
happen on file1 -- it's essentially copying the old version of file1
out of history, so it's a *new node*, which happens to descend from
the old node, and have the same file contents. That's why it's at
r20.
I don't think we can fix this, since it's the fundamental logic of the
svn filesystem at play here. I think you'll need a different way than
$Id$ to notice file uniqueness... something that includes the path?
On Wed, Mar 11, 2009 at 10:37 AM, Laurent F.
<lfournie_at_rockwellcollins.com> wrote:
> Thanks Ben for looking at this issue.
>
> First 'svn list -v local_path_file' or 'svn st -v local_path_file'
> returns the same result on revisions, presented in other order.
> (Note that 'svn list -v bug/*' may be different that 'svn list -v
> bug' )
>
> But the problem is still there:
> Yes tags/tg/file1.txt_at_9 as the same content than tags/tg/file1.txt_at_20
> but I would expect to have $Id$ keyword at rev 9 and not rev 20.
> We cannot count on using a diff tool to check that @20 = @9 or even
> look at the log file !
>
> What is strange is when looking at the log of both file1.txt and
> file2.txt, the last revision is always @20 (the copy command) but in
> one case (file2.txt) the previous revision is used (@13)
> and in the other case ((file1.txt), this is the last revision (@20)
>
> Everything would be OK if svn were selecting the n-1 revision after a
> copy.
>
> Thanks to help solving this issue.
>
> Laurent
>
> NB:
> Ben, all dates here are March 11th (today)...you mix with file size !
>
>
> On Mar 11, 3:14 pm, Ben Collins-Sussman <suss..._at_red-bean.com> wrote:
>> 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.
>>
>>
>>
>> <lfour..._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 bughttp://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&dsMessag...
>>
>> ------------------------------------------------------http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessag...
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1308358
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1308605
Received on 2009-03-11 17:49:24 CET