subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hagen Hentschel (Ellisys)" <hagen.hentsc...@ellisys.com>
Subject RE: resolution of relative external path for given 'peg' revision
Date Thu, 06 Mar 2014 14:24:32 GMT
HI Bert,
 
thank you four your quick response. comments inlined:

________________________________

From: Bert Huijben [mailto:bert@qqmail.nl] 
Sent: jeudi, 6. mars 2014 14:30
To: Hagen Hentschel (Ellisys); users@subversion.apache.org
Subject: RE: resolution of relative external path for given 'peg' revision



At which URL do you set the ‘svn:externals’ property? 

 

>> "/proj/app/b/trunk"

 

And on which URL does the node have when you perform the update? 

 

>> "/proj2/app/b/trunk"

 

The ../../ is applied against the URL the node has at the time of running update/checkout.
If that node has a different url then when you tagged it (and that is a problem) you shouldn’t
have used a node relative external definition. 

 

Update doesn’t check the revision in which the property was set on the directory to determine
which URL to use for resolving relative externals or you would have many other problems 

 

>> I think I get the point. the node may not yet have existed at PEG_REVISION of the
external, so we could not use that one. And arbitrarily chose the "creation revision" would
be a bad idea, indeed.

 

                Bert 

 

Well, I am still confused by the following:

 

If I specifiy PEG_REVISION (@..) to be HEAD and put OPERATIVE_REVISION (-r ...) to the one
*before* moving "proj" to "proj2", it still does not work.

 

Consider the most recent node "/proj2/app/b/trunk/". The 'external' attribute is now '../../../lib/a/trunk@HEAD
-r revisionBeforeMove'.

 

It complains about not finding "/proj/lib/a/trunk". So if it *always* takes the path from
the *current* node revision, where did it get "proj" from, now that the node is *currently*
"proj2"?

 

Thank you,

Hagen 

 

From: Hagen Hentschel (Ellisys) [mailto:hagen.hentschel@ellisys.com] 
Sent: donderdag 6 maart 2014 12:25
To: users@subversion.apache.org
Cc: Hagen Hentschel (Ellisys)
Subject: resolution of relative external path for given 'peg' revision

 

Hi,

 

I am not in the list, so please Cc me for any feedback.

 

I have the following use case that does not work and I think it's a (conceptual) bug with
'pegged' AND 'relative' externals:

 

- consider the following structure (revision 1)

 

/proj/lib/a/trunk/

/proj/app/b/trunk/

 

- now we add a 'pegged' external to check out the lib "a" at its initial revision from within
b (yielding revision 2)

 

proj/app/b/trunk => svn:external := "../../../lib/a/trunk@1 a" (that gets resolved to "/proj/lib/a/trunk@1")

 

- now I simply move "proj" to "proj2" in the repository (yielding revision 3)

 

Now doing a checkout of "proj2"s including the external will not work, claiming there was
"no /proj2/lib/a/trunk at revision 1". Which is utterly true. But why is SVN looking for that
"proj2" path despite me pinning my 'external' to revision "1"? What is the purpose of completing
the relative path using any other revision than 'peg', only to fetch the local copy for the
'peg' revision anyway, no matter what revision I specifiy in the parameters of a checkout
or an update?

 

I think this is a misconception. It should be fixed by respecting the 'peg' revision of an
'external' when resolving the actual path, thus getting the path of the attribute owner for
'peg' revision and not for HEAD or whatever was specified to the command.

 

I am currently not involved as an active developer but I'd offer to become one and provide
a patch if that makes sense to anyone.

 

Greetings,

 

Hagen Hentschel

Senior Software Developer

Mime
View raw message