Bert,
Sorry, but in real life, the delivery I want to make is not always
matching a trunk url, that is why I am using 'svn copy wc tags_url.'
If it were the case, we would only have to remember a build number in
the trunk for delivering and the copy to tags would not
be necessary. If using tags directory is just to give a symbolic name
to release (the name of the root dir in tags), It would be more
efficient for SVN to provide some symbolic alias to any build number.
Note that we can use with some convention the comment of the last
build to give a full symbolic name to the release ("RELEASE
[v1.2.3]...other comment).
I think the solution for delivering is very heavy and would be:
1 - Find the oldest revision I need to include in my release and start
a branch.
. svn copy -rthat_rev trunk/pkg branches/pkg_releaseX
2 - report all changes of the trunk on a file subset that need changes
(as a consequence for those files revision number won't be the same
than in the trunk, so Trac tickets <-> SVN build number will be harder
to manage)
3 - delete files not needed in the delivery
4 - commit the all package and remember the build number (or copy the
branch to tags for that purpose)
Note also that when copying from the head of a branch, one has to
check that his WC is up-to-date (nobody were working on that branch
between the test and the copy).
That way all not changed files will not change there $Id$ revision.
I will have hard time to explain that to projects.
Laurent
On Mar 13, 3:32 pm, Bert Huijben <rhuij..._at_sharpsvn.net> wrote:
> > -----Original Message-----
> > From: Laurent F. [mailto:lfour..._at_rockwellcollins.com]
> > Sent: vrijdag 13 maart 2009 12:01
> > To: d..._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&dsMessag...
> > 63
>
> ------------------------------------------------------http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessag...
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1317775
Received on 2009-03-13 17:50:06 CET