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
> 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
> 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.
Don't you think it's a cleaner UI design if we simply require
--include-externals to commit externals, recursive or not? Sort of protect
the user from doing unintended commits? Of course people usually don't 'svn
commit *', but I could imagine doing 'svn commit sub/dir/*.[hc]' and
forgetting that conf.h is an external in there. Or even "I'm used to
externals being skipped, because I usually use recursive commits and wasn't
aware of that UI detail. Now I've committed nonsense.".
Yeah but I don't think this is such a pressing detail. If you don't think
it's a more betterer UI to always require --include-externals, I'm cool with
that. (Also since my argument goes both ways, as I just noticed.)
If I get my way though, I'll add an error message aborting the commit,
informing about the need for --include-externals.
>> If user wants to commit to a *pegged* external, user should just use a
>> different, non-externals-ized checkout.
> AFAIK, we don't have the means to detect and prevent this action.
But we do :)
See my patch, which uses it.
Received on 2011-08-29 20:47:47 CEST