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
Received on 2009-03-11 16:49:29 CET