C. Michael Pilato wrote on Mon, Aug 29, 2011 at 14:46:40 -0400:
> On 08/29/2011 02:23 PM, Daniel Shahaf wrote:
> > C. Michael Pilato wrote on Mon, Aug 29, 2011 at 12:23:34 -0400:
> >> On 08/29/2011 12:15 PM, Neels J Hofmeyr wrote:
> >>> 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.
> >
> > Did you mean, "no means that don't involve recursing to the parent of
> > the wcroot of the commit target"?
>
> That's not sufficient. We'd have to keep recursing up to the root of the
> volume to get a definitive answer because the definition of an external
> working copy could live in *any* parent directory thereof. I demonstrate
> this simply with the following:
>
> sne-wc-top (an empty wc)
> unversioned
> sne-wc-nested (a different empty wc from svn-wc-top)
> unversioned
> sne-wc-ext (a third, different empty wc, which is an
> external not of its parent, or even of the
> nearest versioned ancestor, or even of any
> item within the nearest versioned wc, but
> of a wc even farther up the tree.)
If you have enough levels of this madness then
- You could have a working copy directory in which every file comes from
a different working copy.
- You could checkout a repository that has one revision and contains no
files or directories into the root directory and get files created at
arbitrary locations in your filesystem.
- You could nest N working copies and have all N try and create the same
dirent_abspath in the host file system [1].
So, I have two responses:
- Don't do that.
- If you do it anyway, make 'svn status' and 'svn info' recognize those
'distant children'.
[1] Neels, when I mentioned shadowing on IRC earlier I referred to
shadowing within one repository, not to cmpilato's overlapping working
copies' example here.)
Received on 2011-08-29 21:11:35 CEST