On 19 Sep 2005 21:22:07 -0500, kfogel@collab.net <kfogel@collab.net> wrote:
> Joshua Varner <jlvarner@gmail.com> writes:
> > [[[
> >
> > Allow working copies to be rooted in symlinked directories.
> > Resolves Issue: 2305.
> >
> > Patch By: Joshua Varner <jlvarner@gmail.com>
> > Review By:
> >
> > * subversion/libsvn_wc/questions.c
> > (svn_wc_check_wc): Changed svn_io_check_path
> > to svn_io_check_resolved_path.
> > * subversion/libsvn_wc/lock.c
> > (probe): Changed svn_io_check_path
> > to svn_io_check_resolved_path.
> >
> > ]]]
> >
> > It looks like both of these are only called on the root of
> > a working copy, (I think) so I don't think there will be
> > any strange side effects of this. I have no way of checking
> > if this fixes Issue 2284 as well, but it might. I used the
> > following script to test, again not converted to proper test
> > yet, I'm really going to look at python one of these days.
>
> > Index: ../svn-trunk/subversion/libsvn_wc/lock.c
> > ===================================================================
> > --- ../svn-trunk/subversion/libsvn_wc/lock.c (revision 16154)
> > +++ ../svn-trunk/subversion/libsvn_wc/lock.c (working copy)
> > @@ -256,7 +256,7 @@
> > {
> > svn_node_kind_t kind;
> >
> > - SVN_ERR (svn_io_check_path (path, &kind, pool));
> > + SVN_ERR (svn_io_check_resolved_path (path, &kind, pool));
> > if (kind == svn_node_dir)
> > SVN_ERR (svn_wc_check_wc (path, wc_format, pool));
> > else
> > Index: ../svn-trunk/subversion/libsvn_wc/questions.c
> > ===================================================================
> > --- ../svn-trunk/subversion/libsvn_wc/questions.c (revision 16154)
> > +++ ../svn-trunk/subversion/libsvn_wc/questions.c (working copy)
> > @@ -54,7 +54,7 @@
> > svn_error_t *err = SVN_NO_ERROR;
> > svn_node_kind_t kind;
> >
> > - SVN_ERR (svn_io_check_path (path, &kind, pool));
> > + SVN_ERR (svn_io_check_resolved_path (path, &kind, pool));
> >
> > if (kind == svn_node_none)
> > {
>
> I think the change in questions.c is safe.
>
> I'm not so sure about the one in lock.c. probe() doesn't always get
> called on the root of a working copy; it gets called on random paths
> in a working copy, and only sometimes on the top dir, I think.
>
> Imagine if a working copy contains a versioned symlink file whose link
> target is another versioned directory. Calling probe() on the symlink
> should get the parent of the link, not of the target. Won't your
> change interfere with that behavior?
If the versioned symlink points to a directory and you want the
svn administrative area for that directory how would you get it?
Do all callers have to check if the file in question is a symlink, and
that the symlink points to a directory. Maybe a new version of probe with
a resolve_symlinks parameter is needed?
The last sentence in the doc string may give a temporary solution:
The first baton in a set, with associated passed as NULL, must have
the longest lifetime of all the batons in the set. This implies it must
be the root of the hierarchy.
I could test if associated is null, and only do a resolved_path call in
that case, that would guarantee it only happens on the root.
>
> Does the patch pass the full test suite?
>
I get an error in ra-local-test, but I get that with a
straight trunk build, too.
START: ra-local-test
lt-ra-local-test: relocation error:
/work/test/svn/svn-trunk/subversion/libsvn_fs/.libs/libsvn_fs-1.so.0:
undefined symbol: svn_ver_equal
END: ra-local-test
These look like more of a problem though:
At least one test FAILED, checking
/shared/lcc51/disk1/work/test/svn/svn-trunk/tests.log
FAIL: diff_tests.py 11: don't diff file marked as binary type
FAIL: special_tests.py 1: general symlink handling
At least one test was SKIPPED, checking
/shared/lcc51/disk1/work/test/svn/svn-trunk/tests.log
SKIP: utf8_tests.py 1: conversion of paths and logs to/from utf8
I think diff_tests.py 11 is related to another change I was working on,
but "special_tests.py 1: general symlink handling" is a problem, it is trying
to double lock a directory. Once for the actual directory, and once for the
symlink to that directory. The associated=NULL check would fix this I believe,
but would require changing probe() to take a resolve links parameter, so before
I do that, does that sound good? Alternatively, the path could be resolved
if it is a symlink in svn_client_info(), but while this would fix this
particular
bug, it doesn't look like a broader fix, and may require similar changes
in other svn_client functions for the similar issues. Or locking could be
changed so that it could check if directories have already been locked in
this particular call, i.e. they had entries in the access baton.
Josh
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Sep 20 17:27:01 2005