"Bert Huijben" <b...@qqmail.nl> writes: > In 1.6 all these cases worked because we found a .svn directory with > metadata in the immediate parent (=the symlinked directory). > > I'm not sure if we really want to support all these corner cases > (including those where this symlink is versioned itself). We never > intentionally broke this feature.
The 1.6 behaviour could be considered a bug. Following unversioned symlinks to the root of a working copy is probably simple enough, but following unversioned symlinks inside a working copy looks far harder. svnadmin create repo svn import -mm repo/format file://`pwd`/repo/A/f svn co file://`pwd`/repo wc ln -s f wc/A/g1 ln -s A wc/B1 svn add wc/A/g1 wc/B1 svn ci -mm wc ln -s f wc/A/g2 ln -s A wc/B2 wc/A/f is a versioned file; the content can be accessed through a variety of paths containing symlinks: wc/A/g1, wc/A/g2, wc/B1/f, wc/B2/f, wc/B1/g1, wc/B1/g2, wc/B2/g1 and wc/B2/g2. Some of the symlinks are versioned and some are unversioned. Now consider: echo new-f > wc/A/f svn st wc/A/g1 svn ci -mm wc/A/g1 wc/A/g1 is versioned so status shows the status of wc/A/g1 not wc/A/f and commit does nothing unless wc/A/g1 is changed. That behaviour looks correct to me. What about the unversioned wc/A/g2? The new 4193 tests seem to assume that Subversion operations should follow this symlink through to wc/A/f. Is it sensible for operations on an unversioned symlink to affect the target while the same operations on a versioned symlink affect the source? That strikes me as very confusing. How should wc/B2/g1 behave? wc/B2 is unversioned but wc/B2/g1 points to wc/A/g1 which is versioned. Do operations on wc/B2/g1 affect wc/A/f? -- Cerified & Supported Apache Subversion Downloads: http://www.wandisco.com/subversion/download
