Re: svn_load_dirs.pl and paths with '@'

Apologies Julian - it was the end of a long day :)

Please find the patch attached... hopefully.

On 20 December 2010 16:57, Julian Foad <julian.foad_at_wandisco.com> wrote:

> 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.
>
>
>