On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> On 08/29/2011 05:48 PM, C. Michael Pilato wrote:
>> No sweat. 'svn commit --include-externals' sounds like a fine plan.
>
> +1 and volunteering.
>
> So by default, *all* externals shall be skipped from commit (dir and file
> externals alike).
>
> When --include-externals is passed to 'svn commit', *all* externals are
> recursed into (dir and file externals alike).
>
> However, an external that has a specific peg revision (file and dir
> externals alike) is never recursively included in commit.
>
> Questions remain about passing externals explicitly:
>
> - 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.
> - when a *pegged* external is passed as explicit target (and say even if
> --include-externals is passed), should we *still* refuse to commit it?
>
> I'd say yes (thinking of 'svn commit *') and yes (thinking of avoiding
> inconsistent external state as seen with file externals, and of changes
> snapping back to peg as seen with dir externals).
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.
As for the second question, I'm +0 on disallowing commits of pegged
externals when not explicitly named. When explicitly name, 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?)
> 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.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2011-08-29 18:24:07 CEST