On 08/29/2011 02:47 PM, Neels J Hofmeyr wrote: > On 08/29/2011 06:23 PM, C. Michael Pilato wrote: >> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote: >>> - when an external is passed as explicit target, still require >>> --include-externals? >> >> No. Because we've recommended in the issue I referenced exactly this >> behavior as a workaround for this missing feature. >>> I'd say yes (thinking of 'svn commit *') >> Is 'svn commit *' really something that people do? I mean, commit is >> recursive by nature, so I'd suspect that 'svn commit' is the more common >> invocation. > [...] >> When explicitly named, though, we've >> always allowed such commits because from the perspective of such an >> operation, we're not looking at an external, just a working copy. (An >> external's external-ness is defined outside it's own scope, right?) > > This is a good point, but IMHO ceases to be one with release 1.7. There no > longer is a detached administrative .svn/ inside an external dir. It really > is an external inside a "real" WC, always detectable, always overlayed.
Really? I'm not so sure. Using the example I brought up elsethread: $ find sne-wc-top -name .svn sne-wc-top/.svn sne-wc-top/unversioned/sne-wc-nested/.svn sne-wc-top/unversioned/sne-wc-nested/unversioned/sne-wc-ext/.svn And I recall arguing against the merging of external working copies into the primary one, too. An externals is an *external*, not an internal. :-) Sadly, we were forced to do so with file externals. (And maybe that's the use-case you were thinking of when you responded above?) -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
