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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-08-29 21:55:12 CEST