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
