On 7/19/07, Blair Zajac <blair@orcaware.com> wrote:
> I'm picking up feature to support relative URLs in svn:externals:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1336
> I would like to get this into 1.5 if possible. The main thing holding
> it up is consensus on the relative URLs that we will support and their
> representations. There's been a large amount of discussion on this, all
> of it on what relative URLs will be allowed and the format of them. The
> discussion stalled in January 2005.
<cut>
> Proposal
> ========
> 1) Be as RFC 3986 compliant as we can.
> 2) The relative URLs are:
> relative to current directory
> ../../branches/1.4.x
> relative to repository root
> ^branches/1.4.x
> relative to server root
> /svn/repos/branches/1.4.x
> relative to scheme
> //svn.collab.net/svn/repos/branches/1.4.x
> Unspecified behavior is how far up ..'s go in relative to the current
> directory URLs.
> Regards,
> Blair
Obviously not a 1.5 extension, but I'd get a concept into the general
awareness of the subversion community: something like externals, but
with expressions that evaluate on the client side.
I have hooked our subversion clients (command line and tortoise) to
support a tag "non-svn:internals" which mimics "svn:externals" except
for three things: no external repository support (rep root only),
relative paths, and variable substitution, where the values of
variables can be set in a configuration setting, and where defaults
may have system dependencies...
Our version is far from fleshed out, as it is intended to allow
platform specific resolution of prebuilt binaries, headers, and so
forth. As such, rather than variables, I simply allowed
single-variable multi-valued selection.
Syntax:
path_element := <directory_string>|'..'
path_elements := <path_element>['/'<path_elements>]
rooted_path := '/'[<path_elements>]
subdir_path := ['./']<path_elements>
rep_path := <rooted_path>|<subdir_path>
category_name := [A-Za-z0-9_-]+
category_key := [A-Za-z0-9_-]+
category_map := <category_key> ' ' <rep_path>
category_maps := <category_map>[ '\n' <category_maps>]
path_choose_list := <subdir_path> '=' '{' <category_name> '\n'
<category_maps> '}'
path_value := <rep_path>|<path_choose_list>
Resulting in an svn:propset of
'non-svn:internals'
with
'<subdir_path> = <path_value>'
... all of the options for category_name and category_key are set at
the repository root in a multi-valued property
"non-svn:internal_category", with a default (if not set) for each, and
a client-side configuration setting for the category_key for each
category_name.
What I wanted, however, was something more akin to
non-svn:internals => "libs =
${propfind:branch_root}/built-libs/${os_name}/${cpu_family}/" where
the values of os_name and cpu_family could be configured to mapped
names in some server setting, using a set of canned client-side tests,
and ${propfind:X} searches up the repository tree for the specified
property key....
I do realize that some of this can be accomplished at lower cost with
a wrapper for co/update/switch/etc. and sparse directories. Still,
that's a pain in the neck... I actually use some switch tricks to do
what I'm doing here, and the difference is minimal...
Again, this would be in addition to, not in place of, the 1.5
concepts, so please, if anyone likes what I'm suggesting, do _not_
derail the relative externals feature in order to push for it. We need
relative externals _soon_, and as far as I can tell, no one other than
my team has felt an overwhelming need for evaluating variables in
externals...
Regards,
Nathan F. Yospe
Core Library and Cross Platform Development
MDM Core, SAP Labs, LLC, Los Angeles, CA
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 16 05:49:00 2007