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 ?
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=1316963
Received on 2009-03-13 15:14:33 CET