Re: svn commit: rev 2821 - trunk/subversion/libsvn_wc trunk/subversion/clients/cmdline trunk/subversion/tests/clients/cmdline

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> > {
> > + /* Sigh. There are non-canonical paths coming in here. */
> > + const char *canonical = svn_path_canonicalize_nts (apr_pstrdup (pool, path),
> > + pool);
>
> I'm not familiar enough with the context, so maybe this isn't a
> problem, but: is it a bug that there are non-canonical paths coming
> in? The public libsvn_wc interfaces should only be receiving
> canonical paths, at least. If it decanonicalizes internally for some
> reason, then the above is understandable. But if it's getting
> non-canonical paths as input, then there's a larger bug somewhere...

In this case the failure was "svn ci" with no explicit target, the
locking code is given a path with a trailing slash.

When I started the access baton stuff, and started storing/comparing
paths I immediately had problems like this. Most of the libsvn_wc
code doesn't appear to care whether paths are canonical, so my guess
is that non-canonical paths get in.

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org