I'm not sure if this is the best way to do it (Garrett?), but I created a /trunk top-level directory with svn:externals pointing to trunk of both java and lucene4c. The drawback is that its https, which means only committers would be able to use it. Is there a better way to do this?
Well, I don't think it'll actually keep non-committers from using it, since mod_authz_svn should only ask for authentication if you try to access something that's restricted. Since those parts of the tree are readable by anyone you won't get prompted unless you try to commit a change.
That said, there are any number of annoying things with svn:externals. They clutter up status output, require you to decide on a single RA layer (https in this case), interoperate badly with tags/branches (less of a problem for this particular use case I guess). A number of commands also behave oddly with them, mainly in that things you expect to recurse into the external (like a commit, if memory serves) don't necessarily do that because externals is kind of a bolted-on after the fact thing, it isn't really baked into the guts of libsvn_wc like you'd want it to be.
In general, I encourage people to avoid them whenever possible, it's just easier to script the checkout of the various parts of the tree you want, or to create dummy directories and script the use of 'svn switch' to pull in the parts you care about. If you really want them then feel free, but I'm not sure they're really needed.
What were you planning on putting in /lucene/trunk other than the externals to pull in other directories? I suppose cross-language unit tests could go there, and that might be a reasonable justification for using externals, although you'll still run into problems when you want to tag or branch that part of the tree, and there isn't a really good solution to that problem.
(If you haven't guessed, I think externals are kind of an embarassing feature of Subversion. They weren't very well thought out in the beginning, and by the time we noticed how much they sucked too many people were using them. I actually argued that we should have removed them before 1.0, to be replaced with something better down the road, but other people felt that the amount of questions about them on the lists implied that a lot of people were in need of them, so they stayed.)
-garrett
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
