I'd like to add my 2c to this thread. If these different types of
relative paths are allowed for externals why not allow them as
arguments to regular commands as well.
so something like:
svn diff ../tags/1.0
would actually work. (you might need some prefix to disambiguate this
from local relative paths).
Perhaps svk's // to indicate the current repository would work.
Assuming a repo layout of project/tags, project/trunk and the latter
being the current wc
//project/tags/1.0 # repo relative
//../tags/1.0 # relative to current dir in current repo.
Would work both for externals and all other commands that take a url
argument.
Michael
On Jan 4, 2005, at 2:02 AM, Max Bowsher wrote:
> Brian W. Fitzpatrick wrote:
>> On Jan 3, 2005, at 11:47 AM, Max Bowsher wrote:
>>> 2. Repository-relative externals.
>>>
>>> Conceptually straightforward (just use RA->get_repos_root()), but
>>> what
>>> syntax should they take? "/branches/foobar/mymodule"?
>>> But, should we also allow relative references to OTHER repositories?
>>>
>>> For example, currently in cvs2svn's repository, we have:
>>> "svntest
>>> http://svn.collab.net/repos/svn/trunk/subversion/tests/clients/
>>> cmdline/svntest"
>>>
>>> Should this be specifyable using something like
>>> "svntest
>>> reposroot:../svn/trunk/subversion/tests/clients/cmdline/svntest"
>>> ?
>>> 3. Host-relative externals.
>>>
>>> Simple in concept, but what syntax to represent?
>>
>> I would prefer to handle both 2 & 3 together. For example,
>>
>> /foo/bar/baz.c
>>
>> Would be used to compose an absolute URL by tacking the host and
>> repository access method onto the front of it. This wouldn't
>> discriminate between repositories on the same host, but instead merely
>> refer to a repository path that starts immediately after host:port/.
>
> This is equal to the syntax proposed in "3. Host-relative externals"
> in my followup "Relative Externals - take 2".
>
> The main problem I see with not having repository level externals:
>
> Suppose subproject A wishes to pin itself to specific QA-ed tags of
> subproject B. It cannot do this via directory-relative externals,
> since trunk and branches/foobar are different depths.
>
> Now suppose the repository has to switch between hosting services. It
> is quite likely the path-to-repository on the server will change, and
> that will require editing the dumpfile.
>
> See my "take 2" followup for another format proposal for
> repository-relative externals.
>
> Max.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jan 4 22:47:00 2005