> -----Original Message-----
> From: Laurent F. [mailto:lfournie_at_rockwellcollins.com]
> Sent: vrijdag 13 maart 2009 12:01
> To: dev_at_subversion.tigris.org
> Subject: Re: Bad revision with svn copy WC -> URL
>
> Ben,
>
> This is really a big problem !
> People here were used to deliver with CVS tag and they'll be
> disappointed with SVN.
> The $name$ and $id$ were the indication that files are coming from the
> right delivery tag and changed files are immediately detected.
>
> This makes more complex the delivering process with SVN.
> If we deliver to customer an export from a tags directory, customer
> receives many source files with changed revision in $Id$, while he
> strongly want to check that those files content has not been touched.
> He should then run a diff tool on those files with the previous
> delivery. This is a huge and fastidious task.
>
> If the changed revision of a given file is equal to the copy command
> build (How he get the proof of that with an export ?), that just means
> that this file has changed on the trunk but a previous version has
> been delivered, but that previous revision is unknown (may be or not
> the revision of the file in the previous customer delivery).
>
> To make short, $Id$ in SVN is not usable since there is cases where
> that revision brings no information.
>
> Am I understanding SVN well or is there another way to build
> deliveries than using svn copy wc->tags_url ?
You can always copy url tags_url. That way you never have a mixed version release.
And doing a "svn update" on your working copy before tagging would have the same effect: all files at the same revision, so no changes below the parent directory.
Bert
>
> Laurent
>
> On Mar 11, 5:48 pm, Ben Collins-Sussman <suss..._at_red-bean.com> wrote:
> > 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.
> >
> >
> >
> > <lfour..._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&dsMessag...
> >
> > ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessag...
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=13169
> 63
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1317484
Received on 2009-03-13 15:32:49 CET