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.)
