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:
revision-property:
libserver = https://...:port
directory-property:
svn:externals = lib $libserver$/svn/libs/myproject/tags/...
CONS:
- no new ones (compared to current situation) AFAICT *g*
(of course all the "problems" mentioned in the book about unversioned
properties)
PROS:
- 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
replication...
- maybe more that I can't think of right now... :-)
Holger
---------------------------------------------------------------------
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