Bug#678346: subversion: svn no longer resolves symlinks (error E155010)
On 2012-06-20 23:12:59 -0500, Peter Samuelson wrote: retitle 678346 subversion: 'svn log' output tricked by symlinks in some cases AFAIK, not just log is affected. tl;dr I'm closing this because I believe it is a bugfix, not a bug. Well, I disagree. The old behavior was a very practical feature. And that's the goal of the symlinks: to be able to access objects through them. I'm marking it found in 1.1.0, not because I've tested it, but because that is when symlink support was added to svn. Actually this is not related to symlink support by svn. There is the same difference with an unversioned symlink inside a working copy. However with a symlink outside a working copy to the root of the WC, this still works. [Vincent Lefevre] svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir foo ln -s foo bar svn add bar touch foo/file svn add foo/file ... svn log bar/file svn: E155010: The node '/tmp/my-test-svn/wc/bar/file' was not found. In other words, 'svn log' is now more consistent between a working copy and a repository. Compare: svn log bar/file svn log file://`pwd`/svn/bar/file Well, a path and a URL are different things. Do not expect them to behave in the same way. On the other hand, a new inconsistency has been introduced on paths (see above). In 1.7, they both fail. In 1.6, one succeeds and one fails. I don't see this as a problem: paths were more powerful, that's all. I think the 1.7 behavior is clearer. There is no object in the repository named 'bar/file', and svn log no longer is fooled into reporting one. Also, links are not resolved at the end of the path. Compare 'svn log foo' with 'svn log bar'. In both 1.6 and 1.7, 'bar' is its own object with its own log, independent of what it points to. Again, I don't see this as a problem. With 1.6, the behavior is similar to the ls command. If the change is really intended, perhaps this should be controlled by an option, with the 3 possible behaviors (1: never resolve symlinks; 2: resolve internal symlinks, like 1.6 and ls; 3: resolve symlinks completely). -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678346: subversion: svn no longer resolves symlinks (error E155010)
On 2012-06-21 09:34:12 +0200, Vincent Lefevre wrote: If the change is really intended, perhaps this should be controlled by an option, with the 3 possible behaviors (1: never resolve symlinks; 2: resolve internal symlinks, like 1.6 and ls; 3: resolve symlinks completely). Actually this is not directly related to symbolic links, but more how a path is resolved (there might be similar problems if one mounts some FS over a versioned directory, though I assume that this is highly discouraged). I would say that a path without a peg revision should follow the usual path resolution mechanism (as described in the path_resolution(7) man page). Paths with peg revision are special and could be seen as some form of relative URL's. Even the current behavior is poorly specified. I've sent a mail to the subversion-users mailing-list. -- Vincent Lefèvre vinc...@vinc17.net - Web: http://www.vinc17.net/ 100% accessible validated (X)HTML - Blog: http://www.vinc17.net/blog/ Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678346: subversion: svn no longer resolves symlinks (error E155010)
Package: subversion Version: 1.7.5-1 Severity: normal After the upgrade from 1.6.17 to 1.7.5, svn no longer resolves symlinks. Consider the following testcase: mkdir my-test-svn cd my-test-svn svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir foo svn ci -m 'add directory foo' ln -s foo bar svn add bar svn ci -m 'add symlink bar to foo' touch foo/file svn add foo/file svn ci -m 'add file' svn up ls -l bar/file svn log bar/file I get an error: svn: E155010: The node '/tmp/my-test-svn/wc/bar/file' was not found. -- System Information: Debian Release: wheezy/sid APT prefers unstable APT policy: (500, 'unstable'), (500, 'testing'), (500, 'stable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.2.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=POSIX, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages subversion depends on: ii libapr1 1.4.5-1.1 ii libc6 2.13-33 ii libsasl2-2 2.1.25.dfsg1-4+b1 ii libsvn1 1.7.5-1 subversion recommends no packages. Versions of packages subversion suggests: pn db5.1-utilnone ii patch 2.6.1-3 ii subversion-tools 1.7.5-1 -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#678346: subversion: svn no longer resolves symlinks (error E155010)
retitle 678346 subversion: 'svn log' output tricked by symlinks in some cases found 678346 1.1.0-1 notfound 678346 1.7.5-1 fixed 678346 1.7.5-1 thanks tl;dr I'm closing this because I believe it is a bugfix, not a bug. I'm marking it found in 1.1.0, not because I've tested it, but because that is when symlink support was added to svn. [Vincent Lefevre] svnadmin create svn svn co file://`pwd`/svn wc cd wc svn mkdir foo ln -s foo bar svn add bar touch foo/file svn add foo/file ... svn log bar/file svn: E155010: The node '/tmp/my-test-svn/wc/bar/file' was not found. In other words, 'svn log' is now more consistent between a working copy and a repository. Compare: svn log bar/file svn log file://`pwd`/svn/bar/file In 1.7, they both fail. In 1.6, one succeeds and one fails. I think the 1.7 behavior is clearer. There is no object in the repository named 'bar/file', and svn log no longer is fooled into reporting one. Also, links are not resolved at the end of the path. Compare 'svn log foo' with 'svn log bar'. In both 1.6 and 1.7, 'bar' is its own object with its own log, independent of what it points to. Peter -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
