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

RE: EXTERNALS table -- good or bad?

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 7 Oct 2011 14:18:31 +0200

> -----Original Message-----
> From: Neels J Hofmeyr [mailto:neels_at_elego.de]
> Sent: donderdag 6 oktober 2011 22:29
> To: Subversion Development
> Subject: EXTERNALS table -- good or bad?
>
> Hi all,
>
> I have committed code to trunk that populates the EXTERNALS table during
> upgrade from 1.6. With a nudge from Philip, I noticed that the EXTERNALS
> table is still a neither-here-nor-there implementation. Now I'm unsure.
>
> This table is / would be very useful if one tries to find all externals
> defined or checked out in a given subtree, without having to first find
and
> then parse all externals skels.
>
> But in fact it is little more than a cache for svn:externals props. It
> duplicates information in a way. But it adds the knowledge of exactly
which
> repository and relpath an external is from (stores URLs in repos-root and
> repos-relpath, readily parsed from the various formats found in
> svn:externals definitions).
>
> So it is useful for speeding up things, but it also has a danger: heavens
> forbid if the EXTERNALS table is ever out of sync with the svn:externals
> props. So, we may often be forced to parse the props anyway (cleanup?).
>
> What do you guys think about the EXTERNALS table? Yay or nay? What
> thought
> has gone into this so far?

There are also quite a few issues resolved by separating the definition and
applied externals in the working copy.

I think you were the one that enabled processing svn:externals on local
additions?
(Impossible without EXTERNALS)

And file externals would be impossible to delete, except when using
EXTERNALS.
(etc.)

        Bert
Received on 2011-10-07 14:19:08 CEST

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.