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
signature.asc
Description: OpenPGP digital signature
