Re: Recurse into same-repos externals at commit time.

On 08/29/2011 06:15 PM, Neels J Hofmeyr wrote:
> - 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 avoiding
> inconsistent external state as seen with file externals, and of changes
> snapping back to peg as seen with dir externals).
>
> If user wants to commit to a *pegged* external, user should just use a
> different, non-externals-ized checkout.

Noting that this is currently only easy enforce for file externals, as they
can't exist across nested WCs.

To block any item inside a pegged dir external, even if passed as explicit
target, one would have to find out for each and every target whether one of
its ancestors is a pegged dir external. So on every commit target, one would
have to scan all the way to the root dir to see if any parent WC has any
svn:externals definition that is an ancestor of this target. Gah.

So a dir ext'l will remain committable if passed as target, even if it is
pegged. By forbidding this for file ext'ls, we decide for another
inconsistency. I'll just stop the recursion to file-ext'ls then.

Thanks for the review!

<thinking-out-loud>All that would be needed to block pegged dir externals is
e.g. that each WC-root's .svn/ has a record somewhere accessible, which
indicates whether this WC was checked out as an external by another WC, and
if so whether it is revision-pegged. Wouldn't even need to know which
WC-root holds its matching svn:externals definition, but might as well store
that too. --I'm probably forgetting a million other things certain others
already thought of before this proposal, as usual.</thinking-out-loud>

~Neels