philip@tigris.org writes:
> --- trunk/subversion/libsvn_wc/lock.c (original)
> +++ trunk/subversion/libsvn_wc/lock.c Wed Jul 31 09:51:20 2002
> @@ -162,7 +162,9 @@
> }
>
> /* Allocate from POOL, intialise and return an access baton. TYPE and PATH
> - are used to initialise the baton. */
> + are used to initialise the baton. PATH is assumed to be canonicalized,
> + paths need to be canonicalized so that path matching and parent-child
> + identification work. */
> static svn_wc_adm_access_t *
> adm_access_alloc (enum svn_wc__adm_access_type type,
> const char *path,
> @@ -172,9 +174,7 @@
> lock->type = type;
> lock->set = NULL;
> lock->lock_exists = FALSE;
> - /* ### Some places lock with a path that is not canonical, we need
> - ### cannonical paths for reliable parent-child determination */
> - lock->path = svn_path_canonicalize_nts (apr_pstrdup (pool, path), pool);
> + lock->path = path;
> lock->pool = pool;
>
> apr_pool_cleanup_register (lock->pool, lock, pool_cleanup,
> @@ -213,11 +213,14 @@
> svn_boolean_t tree_lock,
> apr_pool_t *pool)
> {
> + /* 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...
Just wondering.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 1 17:30:53 2002