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

Re: Relative Externals - format debate

From: Max Bowsher <maxb_at_ukf.net>
Date: 2005-01-04 11:02:47 CET

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
Received on Tue Jan 4 11:05:18 2005

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

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