You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Kevinm <ke...@gmail.com> on 2010/12/20 16:28:39 UTC
svn_load_dirs.pl and paths with '@'
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@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@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@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@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@c.txt
Press return to quit and clean up svn working directory:
Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
dev-kevinm04:~$
Thanks,
Kevin.
Re: svn_load_dirs.pl and paths with '@'
Posted by Julian Foad <ju...@wandisco.com>.
C. Michael Pilato wrote:
> On 12/21/2010 11:33 AM, Julian Foad wrote:
> > Kevinm wrote:
> >> Apologies Julian - it was the end of a long day :)
> >>
> >> Please find the patch attached... hopefully.
> >
> > Yup, it's there.
> >
> > Anyone know how we generate 'svn_load_dirs.pl' from
> > 'svn_load_dirs.pl.in'? I can't seem to find anything in "configure" or
> > "make". I re-built and still it's not there.
>
> Not sure we do this any more. We stripped out all the build support for the
> contrib area back in mid-2009: [...]
Thanks for the info, C-Mike. I committed this in r1051558, without
testing it, and referring to this thread.
Thanks for the patch, Kevin.
- Julian
Re: svn_load_dirs.pl and paths with '@'
Posted by Kevinm <ke...@gmail.com>.
We build and deploy subversion using FreeBSD's ports system. There is a
specific port for svn_load_dirs which replaces SVN_BINDIR and 'corrects' the
path for perl:
${SED} -E \
-e 's|^(#!)/usr/bin/perl[[:>:]]|\1${PERL}|g' \
-e 's|@SVN_BINDIR@|${LOCALBASE}/bin|g' \
${WRKSRC}/svn_load_dirs.pl.in > ${WRKSRC}/svn_load_dirs.pl
On 21 December 2010 16:43, C. Michael Pilato <cm...@collab.net> wrote:
> On 12/21/2010 11:33 AM, Julian Foad wrote:
> > Kevinm wrote:
> >> Apologies Julian - it was the end of a long day :)
> >
> >>
> >> Please find the patch attached... hopefully.
> >
> > Yup, it's there.
> >
> > Anyone know how we generate 'svn_load_dirs.pl' from
> > 'svn_load_dirs.pl.in'? I can't seem to find anything in "configure" or
> > "make". I re-built and still it's not there.
>
> Not sure we do this any more. We stripped out all the build support for
> the
> contrib area back in mid-2009:
>
> r877798 | hwright | 2009-05-14 11:01:28 -0400 (Thu, 14 May 2009) | 16 lines
> Changed paths:
> M /subversion/trunk/Makefile.in
> M /subversion/trunk/build.conf
> M /subversion/trunk/configure.ac
> M /subversion/trunk/tools/dist/dist.sh
>
> Following up on my threats to remove contrib/ from our distribution:
> * Don't ship contrib/ in our distribution tarball
> * Remove contrib/ from our configure and build process
>
> * Makefile.in
> (contribdir): Remove.
>
> * build.conf
> (svn-push): Remove.
>
> * tools/dist/dist.sh:
> Strip contrib/ from the distribution tarballs.
>
> * configure.ac:
> Don't configure contrib scripts.
>
>
> --
> C. Michael Pilato <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
Re: svn_load_dirs.pl and paths with '@'
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 12/21/2010 11:33 AM, Julian Foad wrote:
> Kevinm wrote:
>> Apologies Julian - it was the end of a long day :)
>
>>
>> Please find the patch attached... hopefully.
>
> Yup, it's there.
>
> Anyone know how we generate 'svn_load_dirs.pl' from
> 'svn_load_dirs.pl.in'? I can't seem to find anything in "configure" or
> "make". I re-built and still it's not there.
Not sure we do this any more. We stripped out all the build support for the
contrib area back in mid-2009:
r877798 | hwright | 2009-05-14 11:01:28 -0400 (Thu, 14 May 2009) | 16 lines
Changed paths:
M /subversion/trunk/Makefile.in
M /subversion/trunk/build.conf
M /subversion/trunk/configure.ac
M /subversion/trunk/tools/dist/dist.sh
Following up on my threats to remove contrib/ from our distribution:
* Don't ship contrib/ in our distribution tarball
* Remove contrib/ from our configure and build process
* Makefile.in
(contribdir): Remove.
* build.conf
(svn-push): Remove.
* tools/dist/dist.sh:
Strip contrib/ from the distribution tarballs.
* configure.ac:
Don't configure contrib scripts.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn_load_dirs.pl and paths with '@'
Posted by Julian Foad <ju...@wandisco.com>.
Kevinm wrote:
> Apologies Julian - it was the end of a long day :)
>
> Please find the patch attached... hopefully.
Yup, it's there.
Anyone know how we generate 'svn_load_dirs.pl' from
'svn_load_dirs.pl.in'? I can't seem to find anything in "configure" or
"make". I re-built and still it's not there.
- Julian
> On 20 December 2010 16:57, Julian Foad <ju...@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@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@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@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@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@c.txt
> > Press return to quit and clean up svn working directory:
> > Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
> > dev-kevinm04:~$
> >
> >
> > Thanks,
> >
> >
> > Kevin.
>
>
>
>
>
Re: svn_load_dirs.pl and paths with '@'
Posted by Kevinm <ke...@gmail.com>.
Apologies Julian - it was the end of a long day :)
Please find the patch attached... hopefully.
On 20 December 2010 16:57, Julian Foad <ju...@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@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@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@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@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@c.txt
> > Press return to quit and clean up svn working directory:
> > Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
> > dev-kevinm04:~$
> >
> >
> > Thanks,
> >
> >
> > Kevin.
>
>
>
Re: svn_load_dirs.pl and paths with '@'
Posted by Kevinm <ke...@gmail.com>.
Apologies Julian - it was the end of a long day :)
Please find the patch attached... hopefully.
On 20 December 2010 16:57, Julian Foad <ju...@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@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@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@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@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@c.txt
> > Press return to quit and clean up svn working directory:
> > Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
> > dev-kevinm04:~$
> >
> >
> > Thanks,
> >
> >
> > Kevin.
>
>
>
Re: svn_load_dirs.pl and paths with '@'
Posted by Julian Foad <ju...@wandisco.com>.
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@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@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@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@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@c.txt
> Press return to quit and clean up svn working directory:
> Cleaning up /tmp/svn_load_dirs_SfwwQDtsAX
> dev-kevinm04:~$
>
>
> Thanks,
>
>
> Kevin.