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

Relative svn:externals format

From: Christopher Key <cjk32_at_cam.ac.uk>
Date: Fri, 25 Jan 2008 14:06:41 +0000

Hello,

I'm not sure if this belongs here or on the developers list, please let
me know if it would be more appropriate elsewhere.

Anticipating the upcoming release of SVN 1.5, I decided to have a play
with the new relative externals, and almost immediately ran into a problem,

# svnadmin create /tmp/repo1
# svnadmin create /tmp/repo2
# svn co file:///tmp/repo1 /tmp/wc
Checked out revision 0.
# svn ps svn:externals "external1 ^/../repo2" /tmp/wc
svn: Invalid svn:externals property on '/tmp/wc': target '^/../repo2' is
an absolute path or involves '..'

After looking at the source code, it appears that the problem is the
ambiguity introduced with relative externals, making it unclear whether
you mean "URL DIR" or "DIR URL", and the code is assuming the former.
Accordingly, if I instead do,

#svn ps svn:externals "^/../repo2 external1" /tmp/wc
property 'svn:externals' set on '/tmp/wc'

then all is well.

My point is whether this is the correct assumption to make. All the
documentation I've seen uses externals in the form "DIR URL", e.g.
http://svnbook.red-bean.com/en/1.0/ch07s03.html, and indeed I wasn't
aware that the form "URL DIR" was even valid. Would it be sensible to
standardise on one representation, silently assume this representation
where there's ambiguity, and issue a deprecation warning where the
external is unambiguously contradictory. My personal preference would
be for "DIR URL", both because it's easier to read, and because that's
what the documentation uses.

Regards,

Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-25 15:07:33 CET

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

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