[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: setting explicit revision for relative externals fails during tag

From: Stefan Küng <tortoisesvn_at_gmail.com>
Date: Wed, 15 May 2013 20:38:02 +0200

On 15.05.2013 14:48, btfritz_at_rockwellcollins.com wrote:
> I've attached a .bat file (renamed as a .txt file to bypass email
> filters where I work) which will create a pair of repositories to
> demonstrate multiple (possibly related) issues I'm having with
> relative-path svn:externals definitions. Some of these issues may have
> been discussed at
> http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2959353but
> I could not easily tell if the situation was the same (descriptions were
> a little vague in my eyes) nor do I see any action taken.
>
> Open the attachment in your favorite text editor and examine it to make
> sure it's not doing anything you don't expect. Then, rename the file to
> have a .bat extension and run it from some temp directory. It will
> create two repositories and working copies for each in whichever
> directory you run it from.
>
> After the .bat script runs, open the "trunk" folder of the testrepo_wc
> working copy and use TortoiseSVN to open the "create tag" dialog. Now
> you can see the first problem. The "other_subdir" external is shown at
> revision 1, which is in fact the last time the contents being pulled in
> were changed directly. However, at revision 2, there was a svn mv
> command that renamed the parent directory of sub3 in the externrepo, so
> the current working copy is ACTUALLY pulling in revision 2, not revision 1.
>
> Now select all the external items to set the explicit revisions, and
> create the tag. Tag creation should appear to succeed. Now go to the
> "tags" directory in the working copy and do an svn update. Both
> externals will fail.
>
> The first external (for subdir inside testrepo) fails because it tries
> to access the relative external path at revision 1. But the tag did not
> exist at revision 1. This external should have been translated to a less
> relative path on trunk (probably using ^/trunk/subdir instead of
> ../subdir) or should have been updated to the revision resulting from
> tag creation. This is problem 2.
>
> The second external fails because it tries to use revision 1, when as
> discussed above it ought to be using revision 2 due to the parent
> directory move. Problem 3.
>
> A fourth problem can be seen by bringing up the svn:externals editor on
> /trunk/externals. Try doing a "show log" for the testrepo external. When
> I do this, I see a message: "File not found, revision 4, path
> '/trunk/externals/../subdir/../subdir'" and no log.
>
> Both problematic use cases follow patterns documented at
> http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html
>
> Normally I'd post separately for these issues but I thought they might
> be related since they all have to do with relative externals paths, and
> my test repositories can easily reproduce each of them. Let me know if
> you'd rather discuss them separately.

Thanks a lot for the very detailed description of the problem(s), and
the script to reproduce this.

You're right of course that the problem is because the revision is
wrong. And if the correct revision is used, all other problems go away.

I've committed a fix for this in r24191, so in the upcoming version 1.8
it will work correctly.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
------------------------------------------------------
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=3055631
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2013-05-15 20:38:12 CEST

This is an archived mail posted to the TortoiseSVN Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.