PATCH for issue #1336 (to allow relative URL's in svn:externals)

These patches are against Revision 10392.

- Making svn_path_canonicalize() handle '../' as documented in svn_path.h

        M subversion/libsvn_subr/path.c

- Making svn:external allow relative paths:

        M subversion/include/svn_wc.h
        M subversion/libsvn_wc/props.c
        M subversion/libsvn_client/externals.c

  A URL is recognized as relative only when it begins with '.' or '/'.
  "./" can appear in the relative URL (even initially!)
  and it has the usual meaning.

  Example:

        $ svn info
        URL: http://host.domain/path/to/repos/moduleI/subdirA/subdir1

        $ svn propget svn:externals .
        subdir2 ../subdir2
        subdirB ../../subdirB
        subdirC /path/to/repos/moduleI/subdirC
        subdirD /path/to/repos/moduleII/subdirD

        $ svn subdir2 subdirB subdirC subdirD
        Path: subdir2
        URL: http://host.domain/path/to/repos/moduleI/subdirA/subdir2

        Path: subdirB
        URL: http://host.domain/path/to/repos/moduleI/subdirB

        Path: subdirB
        URL: http://host.domain/path/to/repos/moduleI/subdirC

        Path: subdirB
        URL: http://host.domain/path/to/repos/moduleII/subdirD

Proposal enhancement:
  Repository-relative paths.

  e.g. when the above svn:externals property contains one more line:
        subdirE .../moduleIII/subdirE

  Then, this should expand to
        http://host.domain/path/to/repos/moduleIII/subdirE

  avoiding the need to specify "/path/to/repos".

Relative URLs are useful for repository/host-local references,
allowing an experimental/internal SVN server/repository to be
relocated without the need to fix all the svn:externals properties.

Of course, there are always ways to break relative references, in the
same way symbolic links with a relative destination may break after a
directory restructuring. But even absolute URLs can break: the host
being renamed (e.g. a company being renamed; an OSS project being
renamed); the /path/to/repos being moved, etc. The more common case
may be different URL schemes (http? https? svn?) being used depending
on whether you're on the Internet or Intranet. I think we should
leave it up to the end-users to resolve the potential problems, rather
than forbidding relative URLs in svn:externals.

-- 
Sau Dan LEE                     §õ¦u´°(Big5)                    ~{@nJX6X~}(HZ) 
E-mail: danlee@informatik.uni-freiburg.de
Home page: http://www.informatik.uni-freiburg.de/~danlee

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org