Hyrum K Wright wrote on Sat, Apr 21, 2012 at 16:14:54 -0500: > On Fri, Apr 20, 2012 at 9:47 AM, C. Michael Pilato <cmpil...@collab.net> > wrote: > > On 04/19/2012 01:37 PM, Julian Foad wrote: > >> C. Michael Pilato wrote: > >> > >>> I guess I don't see this as "whack-a-mole with 'svn > >>> import'". 'svn import' is treated uniquely because it is > >>> genuinely unique -- no other Subversion operation tries to > >>> directly replicate unversioned data in the repository without > >>> first "staging it" in the working copy state. The only other > >>> thing > >>> that comes close is 'svn mkdir URL' (which, by the way, doesn't > >>> appear to be > >>> disallowing the creation of .svn/ directories ... oops!). > >> > >> And > >> svn copy --parents ... $URL/foo/.svn/bar > >> svn move --parents ... $URL/foo/.svn/bar > >> > >> All four of these commands are "genuinely unique" in this common way :-P > > > > Yeah, copy and move occurred to me in the shower this morning. So much for > > uniqueness. :-( > > Not to mention the fact that the check as currently constructed is > platform-dependent. > > If you do an import with the ASP_DOT_NET_HACK (or whatever it's > called) enabled, the import will error on _svn, *not* .svn, whereas > the standard procedure would like _svn slip right by. This is all > crazy since this is strictly a repository operation, and shouldn't be > dependent upon client-side specifics. Good luck getting that all to > behave as advertised in a mixed-platform environment.
svn_wc_is_adm_dir()
