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

"svn link" v's relative externals

From: Chris Leishman <chris_at_leishman.org>
Date: 2005-09-14 03:41:05 CEST

Hi all,

I've been following the discussion/planning around relative
svn:externals:

  http://subversion.tigris.org/issues/show_bug.cgi?id=1336

There is also an associated issue requesting that transactional commits
follow relative externals:

  http://subversion.tigris.org/issues/show_bug.cgi?id=2402

Now, I have a thought which I'm throwing into the mix. What if, instead
of allowing repository relative externals to be included in
svn:externals, there was instead another way of creating a 'link' within
the repository.

This could be facilitated via a different property (eg. svn:links) or
via a more integrated mechanism such as a new 'link' command. It would
operate in a similar manner to a copy, except that it would continue to
track changes made to the resource in other locations.

This would implicitly resolve issue 2402, and solve the issue in 1336 of
exactly how to describe a repository relative location with a URI.

I'm not well versed on the internal structure of subversion, but I
imagine each resource is identified uniquely within the repository (via
the UUID), so it may be possible to the same UUID present in more than
one directory entry - or something along those lines.

There are arguments against using such a mechanism, mostly from a source
management perspective (eg. a change in one location, whilst tested, may
break code in another place due to the shared nature of the file). But
I think it would be the option of the user to make use of this or not -
and other source management tools provide just such a feature.

Thoughts?

chris

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Sep 14 03:41:57 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.