Reported as bug #3416
(http://subversion.tigris.org/issues/show_bug.cgi?id=3416).
Marián
Marian Petras wrote:
> Hello,
>
> I am re-posting this question about a possible bug in Svn because I got
> no response on the users' mailing list (for the original e-mail, see
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2300569).
>
> I cannot 'svn add' or 'svn commit' a file if the file's name starts with
> an at sign (@) and the specified file path contains at least one
> directory element.
>
> For example, I would expect the following behavior:
>
> $ svn add 'dir/@File.txt'
> A dir/@File.txt
>
> but I get
>
> $ svn add 'dir/@File.txt'
> svn: warning: 'dir_at_File.txt' not found
>
> (Note the missing slash in the Svn output.)
>
> Appending an extra at sign to the end of the path does not help:
>
> $ svn add 'dir/@File.txt@'
> svn: warning: 'dir/@File.txt@' not found
>
> Now the slash was maintained but the trailing at sign was maintained,
> too, which makes the path invalid.
>
> This issue can be quite easily worked around by first changing to the
> directory containing the file, invoking "svn add @File.txt" (i.e.
> without any directory element in the file's path) and changing back to
> the original directory:
>
> $ cd dir
> $ svn add '@File.txt'
> A @File.txt
> $ cd ..
>
> The more serious problem is that 'svn commit' fails the same way:
>
> $ svn commit -m 'added file' 'dir/@File.txt'
> svn: Commit failed (details follow):
> svn: '/home/mp/wc/dir_at_File.txt' is not under version control
>
> $ svn commit -m 'added file' 'dir/@File.txt@'
> svn: Commit failed (details follow):
> svn: '/home/mp/wc/dir/@File.txt@' is not under version control
>
> In some cases, this issue can be worked around by committing the whole
> directory. But it is not an option if a subset of files in the given
> directory is to be committed.
>
> I attached a test script (for Unix-like systems). It creates two
> subdirectories in the current directory ("working-copy", "test-repo")
> and runs a test on them, displaying the executed commands on the console
> as if invoked by the user.
>
> Environment:
>
> Operating system:
>
> Linux - Debian Lenny running on x86-64
>
> Subversion info:
>
> Svn version 1.6.2 (r37639), compiled with:
>
> gcc (Debian 4.3.2-1.1) 4.3.2
>
> Configuration options:
>
> --with-berkeley-db=db.h:/usr/include:/usr/lib:db-4.6
> --with-gnome-keyring
> --enable-javahl
> --with-jdk=/usr/local/java/jdk1.5.0_18
> --with-junit=/usr/local/java/junit3.8.1/junit.jar
>
> uname -m = x86_64
> uname -r = 2.6.26-1-amd64
> uname -s = Linux
> uname -v = #1 SMP Fri Mar 13 17:46:45 UTC 2009
>
> No private modifications.
>
> Berkeley DB: 4.6
>
> The problem is only with the command-line client. When JavaHL is used to
> invoke the equivalent commands, everything works. This was discovered
> during evaluation of a bug reported to the NetBeans project
> (http://www.netbeans.org/issues/show_bug.cgi?id=165329). The Subversion
> module of the NetBeans IDE prefers JavaHL but if it does not find one,
> it falls back to using the command-line client.
>
> I have also reproduced this behavior on the following systems:
>
> Linux (Debian Lenny, x86-64)
> Subversion version 1.5.1 (r32289)
>
> Linux (openSUSE, x86-64)
> Subversion version 1.6.0 (r36650)
>
> Windows XP 32-bit
> Subversion version 1.6.1 (r37116)
>
>
> Marián Petráš
> developer of the NetBeans IDE
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2353599
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2355825
Received on 2009-05-28 07:32:14 CEST