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

RFE? RFC! summary: svn:externals - question: changed (external) hostname => DEAD revisions?

From: Holger Stratmann <tigris_at_finch.de>
Date: 2005-08-27 17:03:04 CEST

Hi guys,

thanks for your answers - I guess they've pretty much defined/clarified
what's possible and what's not... (currently).
Here's a quick summary and (imho) a sensible RFE which is "clean" and
not too much work.

Comments about my idea?

Ben Collins-Sussman wrote:

>> Yes, any NEW revisions will be ok, but what about the old ones?
>> Also, I'd need to "fix" any branch and tag (which shouldn't even be
>> possible for tags) ever created and *still* wouldn't be able to
>> access "older" revisions from the branches
> Aha, I get it, yeah.
> That could be annoying. I think the only solution is to solve the
> problem outside Subversion, by setting up some sort of /etc/hosts
> re-mapping.

Yes, that seems to be a good solution for "immediate pain" (if the old
server doesn't exist any longer and/or never needs to be accessed again
*g*) - however, I'd need to communicate this to everybody who wants to
access the history... (and, btw: won't work if the port is different)
The "concept" of "hosts-remapping" is part of my suggested solution :-)

I just realised that I could probably also dump, fix and reload the
repository. Good enough to reduce my "fear" of using externals, but
still not "nice".

> This problem is also a good reason why we need "relative" urls in
> svn:externals.

Aaron Wood wrote:

>Allowing server-relative paths would alleviate the problem for
>external respositories on the same server (much like how most web
>developers I know never use absolute pathnames if they can help it).
Yes, server(!)-relative paths would solve my problem (as opposed to
"repository-relative" paths).

When these are implemented, you can probably integrate my idea with
almost zero (ok, let's say very little) overhead:

my idea:
Well, before I start writing and to avoid some comments I've already
thought about: I think the whole concept of "externals" is "quite
dangerous" and violates several concepts of a version control system
(pretty much results in "unversioned (sub-)directories"). It should be
used very carefully. My suggestion does not eliminate those problems,
but IMHO makes them a bit more "manageable".

MY IDEA (now, really :-):
Along with and in addition to relative paths, I'd like to reference
revision properties in file/revision properties:
    libserver = https://...:port
    svn:externals = lib $libserver$/svn/libs/myproject/tags/...

- no new ones (compared to current situation) AFAICT *g*
(of course all the "problems" mentioned in the book about unversioned

- I can easily "fix" older revisions by "updating" the
revision-property. This is like "hosts-remapping" *g* (but done on the
server, not per user)
- used wisely, this is a more "verbose" solution, because I can easily
see any "external dependencies" instead of iterating through my entire
tree looking for "svn:externals" - I guess I might prefer this over
(server-) relative paths for links to a different repository!
- several references to the same server are kept in one place and only
require one change
- there may be other uses for this funtionality, thus reducing data
- maybe more that I can't think of right now... :-)


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Aug 27 17:04:41 2005

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

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