Christian Daudt wrote:
> I know svn:externals doesn't come close to solving these situations, but it
> is certainly a huge step forward from scripts having to scramble to get
> together information which IMHO rightfully belongs in svn. Before
> svn:externals fully solves this, you'd have to be able to create rules as to
> what happens to the component modules when you copy/rename/remove the
> meta-modules (e.g. possibly using a regexp substitution to determine how to
> copy/rename each component). The fact that people have have problems with
> svn:externals is because they are trying to stretch it to get the most out of
> what it currently offers (myself included).
The problem is that with our current design making that kind of support
(which is really the thing that might make externals worthwhile) work
would require a ton of effort. Making it happen with today's repository
would just be ridiculously slow. One of the nice things about
Subversion is that branching and tagging is constant time, but that will
go away real fast if in the process of making a copy you have to search
all over the place for externals to update... So to make it fast
externals would require some way to track the parts of the repos that
have svn:externals properties, so that search could be fast, so we're
getting in to a lot of extra work. I'm not saying it wouldn't be nice
to have, but I am saying that these kind of thigns need to be thought
out and planned, and I don't think they were when we first added support
for svn:externals to the tree. Perhaps we can do a better job (and have
a more useful feature) if we cut it now and rework it (or something like
it) as a post-1.0 feature.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 23 19:31:22 2003