Hmmm.
At first I thought this patch was a bogus approach. After all,
someone doing autoversioning (for example) could still drag-n-drop an
item named ".svn" over to their repository, bypassing our client code
entirely.
But so what? As Mike just pointed out to me, such a user might not
even have a working copy at all. Sure, they'll run into interop
problems if they try to cooperate with someone who _does_ have a
working copy, but that's just something they have to know. (They can
always remove the ".svn" item from the repository later.) There's
still no reason our own client code can't protect against this, as it
already does for imports.
So +1, even though it somewhat contradicts my earlier mail on this
thread :-).
-K
cmpilato@collab.net writes:
> Try this, and if it works, someone should probably commit it up. (I'm
> not in a good testing state right now).
>
> Index: subversion/libsvn_client/add.c
> ===================================================================
> --- subversion/libsvn_client/add.c (revision 5448)
> +++ subversion/libsvn_client/add.c (working copy)
> @@ -189,6 +189,14 @@
>
> *commit_info = NULL;
>
> + /* Split the new directory name from its parent URL. */
> + svn_path_split (path, &anchor, &target, pool);
> + target = svn_path_uri_decode (target, pool);
> + if (strcmp (target, SVN_WC_ADM_DIR_NAME) == 0)
> + return svn_error_createf
> + (SVN_ERR_RA_ILLEGAL_URL, NULL,
> + "The directory `%s' is reserved for administrative use.", target);
> +
> /* Create a new commit item and add it to the array. */
> if (ctx->log_msg_func)
> {
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 26 20:37:21 2003