[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn_load_dirs.pl and paths with '@'

From: Julian Foad <julian.foad_at_wandisco.com>
Date: Mon, 20 Dec 2010 16:57:30 +0000

Hi Kevin.

Thanks for contributing this bug fix.

'@' is called an 'at' sign; '&' is called an ampersand.

Unfortunately your patch didn't reach the mailing list, probably because
the mailing list strips attachments that it doesn't recognize as a plain
text MIME type. You could try renaming it as ".txt" to encourage your
mail program to set the MIME type properly.

- Julian

On Mon, 2010-12-20 at 16:28 +0000, Kevinm wrote:
> I stumbled across a bug in svn_load_dirs.pl when importing paths with
> an ampersand character. Anything after the final ampersand in a path
> gets interpreted as a peg revision during the add phase, so the
> affected files don't get imported and the sanity check at the end
> fails.
>
>
> I have attached a patch to get around the issue; it always adds
> an ampersand to the end of each path while building the TARGETS file.
> This is documented in the svn book
> here: http://svnbook.red-bean.com/en/1.5/svn.advanced.pegrevs.html
>
>
> The perceptive reader is probably wondering at this point
> whether the peg revision syntax causes problems for working
> copy paths or URLs that actually have at signs in them. After
> all, how does svn know whether news_at_11 is the name of a
> directory in my tree or just a syntax for “revision 11 of
> news”? Thankfully, while svn will always assume the latter,
> there is a trivial workaround. You need only append an at sign
> to the end of the path, such as news_at_11@. svn cares only about
> the last at sign in the argument, and it is not considered
> illegal to omit a literal peg revision specifier after that at
> sign. This workaround even applies to paths that end in an at
> sign—you would use filename@@ to talk about a file named
> filename@.
>
>
> Below is a simple test to reproduce the issue:
>
>
> dev-kevinm04:~$ mkdir test
> dev-kevinm04:~$ touch test/a.txt
> dev-kevinm04:~$ svnadmin create repos
> dev-kevinm04:~$ svn_load_dirs -v -t 1.0 file://`pwd`/repos current
> test
> Directory test will be tagged as 1.0
>
>
> <snip>
>
>
> Cleaning up /tmp/svn_load_dirs_a_cRabZpNS
> dev-kevinm04:~$ touch test/b_at_c.txt
> dev-kevinm04:~$ svn_load_dirs -v -t 2.0 file://`pwd`/repos current
> test
> Directory test will be tagged as 2.0
>
>
> <snip>
>
>
> Checking out file:///home/london/kevinm/repos/current
> into /tmp/svn_load_dirs_SfwwQDtsAX/my_import_wc
> Running /usr/local/bin/svn checkout --non-interactive
> file:///home/london/kevinm/repos/current my_import_wc
>
>
> Loading test and will save in tag 2.0.
> A b_at_c.txt
> Running /usr/local/bin/svn add -N
> --targets /tmp/svn_load_dirs_SfwwQDtsAX/targets.00001
> Running /usr/local/bin/svn commit --non-interactive -m Load test into
> current.
>
>
> Running /usr/local/bin/svn update --non-interactive
> Running /usr/local/bin/svn cp --non-interactive -m Tag current as 2.0.
> file:///home/london/kevinm/repos/current
> file:///home/london/kevinm/repos/2.0
> Checking out file:///home/london/kevinm/repos/2.0
> into /tmp/svn_load_dirs_SfwwQDtsAX/my_tag_wc_named_2.0
> Running /usr/local/bin/svn checkout --non-interactive
> file:///home/london/kevinm/repos/2.0 my_tag_wc_named_2.0
> Running diff -u -x .svn -r
> test /tmp/svn_load_dirs_SfwwQDtsAX/my_tag_wc_named_2.0
> /usr/local/bin/svn_load_dirs: diff -u -x .svn -r
> test /tmp/svn_load_dirs_SfwwQDtsAX/my_tag_wc_named_2.0 failed with
> this output:
> Only in test: b_at_c.txt
> Press return to quit and clean up svn working directory:
> Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
> dev-kevinm04:~$
>
>
> Thanks,
>
>
> Kevin.
Received on 2010-12-20 17:58:17 CET

This is an archived mail posted to the Subversion Dev mailing list.