The usual order for badly designed/architected/implemented things is to
design/architect/implement a better one *and then* pull the plug on the bad
one, not just yank it and say: "hold your breath (and projects) until the
replacement comes around".
csd
On Wednesday 23 July 2003 10:30, Garrett Rooney wrote:
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 23 20:19:19 2003