David Glasser writes:
> On 5/9/07, Peter Lundblad <plundblad@google.com> wrote:
> > For svnserve, this adds three extra roundtrips just for the sanity check
> > (not saying it is the wrong tradeoof if there's no other way) and
> > reconnects twice if you're working against anolder server.
> > Is there a cheaper way to do it? Is it possible to check for a specific
> > error returned from the server?
> > (I don't have the sources handy ATM, so that might be a too easy question
> > to anser...)
>
> The error is generated in libsvn_repos/reporter.c(drive):
>
> /* If the anchor is the operand, the source and target must be dirs.
> Check this before opening the root to avoid modifying the wc. */
> else if (!*b->s_operand && (!s_entry || s_entry->kind != svn_node_dir
> || t_entry->kind != svn_node_dir))
> return svn_error_create(SVN_ERR_FS_PATH_SYNTAX, NULL,
> _("Cannot replace a directory from within"));
>
That's an amazing error code! If I remember correctly, this is generated
when an editor run tries to delete the root of the edit.
I think the "replace" word comes from someone thinking of a specific case
when this could happen. But we should definitely be able to have a specific
error code for this. (That does obviously not fix the problem for older
servers.(
> The reporter code is invoked for much more than just switch, and this
> particular error covers more cases than just the issue at hand. I
> thought about making it return a more specific error based on exactly
> what s_entry->kind and t_entry->kind was, but I'm not incredibly
Why does it matter exaclty what the kinds are? If the client got a more specific
error code, it coudl generate a better error message based on what it is
trying to do.
> familiar with the reporter code, and catching the invalid input as
> soon as it occurs seemed to be less invasive.
>
Sure, but we know from DAV that ltos of roundtrips aren't exactly cheap;)
That's why I'm skeptical about adding three without further investigation.
> (On the other hand, arguably this is never a useful error message. I
> haven't quite figured out all the cases that it can occur yet.)
Updting when yuor update target was removed/renamed is one example I can think
of. I guess this is where the actual message stems from.
>
> The reparents shouldn't be able to fail at least, right?
>
Of course they can, but why's that relevant?
Best,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 10 05:47:41 2007