You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@subversion.apache.org by Onno van der Straaten <on...@gmail.com> on 2010/06/23 13:29:36 UTC

Re: Space in filename causes path not found on commit

Hi all,
I posted message below to the users list and got no response. Should I
create a bug report for this?
Thanks and Regards,
Onno

On Sat, Jun 19, 2010 at 3:33 PM, Onno van der Straaten <
onno.van.der.straaten@gmail.com> wrote:

> Hi all,
>
> I'm trying to cleanup a repository a bit. While renaming and moving
> files/folders I noticed that commit at times fail with the message "path not
> found". I think this is caused by filenames with spaces.
>
> I could easily reproduce this on a personal repository
>
> I have a co of a folder with two subfolders
>
> my-laptop ~/my_wc $ ls
> folder 1 folder 2
>
> Rename folder 2 to folder 3
> my-laptop ~/my_wc $ svn move "folder 2" "folder 3"
> A folder 3
> D folder 2/file with spaces.txt
> D folder 2
>
> Move file to folder 1
> my-laptop ~/my_wc $ svn move "folder 3/file with spaces.txt" "folder 1/file
> with spaces.txt"
> A folder 1/file with spaces.txt
> D folder 3/file with spaces.txt
>
> Commit
> my-laptop ~/my_wc $ svn commit --message "test"
> Adding folder 1/file with spaces.txt
> svn: Commit failed (details follow):
> svn: '/svn/!svn/bc/1101/test/folder%202/file' path not found
>
> If I issue the commands on a file without spaces (replace space with
> underscore) the commit is successful.
>
> If I reverse the commands, I move the file and then rename the folders, the
> commit also fails but with a different error message
>
> svn: Item '/test/folder 2' is out of date
> After that I was unable to recover my working copy to a working state. It
> reports tree conflict. svn cleaup, svn revert, svn up didn't help.
>
> Is this a known problem? Shouldn't this just work regardless of spaces in
> filenames and/or order of the commands?
>
> BTW, I'm using Linux Mint and  svn client version 1.6.5 (r38866).
> Repository is *version 1.5.1 (r32289).*
>
> Thanks in advance,
> Onno
>

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Philipp Marek <ph...@linbit.com>.

Hello Julian,

On Friday 02 July 2010, Julian Foad wrote:
> Then we can work on extending the principle in one or more different
> ways, which, I'm sure, will detect a bunch of bugs:
> 
>   * space in some of the within-WC paths;
> 
>   * other ASCII pathnames that require URI-escaping, or in any other way
> have the potential to be mis-handled by Subversion;
> 
>   * non-ASCII characters (but the ability to do this would depend on
> what locales the test platform supports, and so would require
> configuration magic to enable it);
> 
>   * similar things for repository-side paths.
I just want to mention that I'm doing something like this in the FSVS tests.

I've got a test script that runs the tests for
 * the current locale,
 * an UTF8 locale, and
 * a non-UTF8 locale (these are found via "locale -a | grep").

My Makefile defines an UTF8-string, and a localized string (via "$(shell 
date +%b -d2001-01-27)", which, for german locales, conveniently returns 
"Jän").
These strings are then used for directory and filenames, contents, and in 
lots of other places where something might go wrong.

If you want to take a look - here's the Makefile:
  http://fsvs.tigris.org/source/browse/fsvs/branches/fsvs-1.2.x/fsvs/tests/Makefile.in?revision=2387&view=markup

Regards,

Phil

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by "C. Michael Pilato" <cm...@collab.net>.

We could replace the Greek tree with files like "mu X" where X is the Greek
'mu' character.  :-)

On 07/02/2010 06:42 AM, Julian Foad wrote:
> Philip Martin wrote:
>>>>> Adding folder 1/file with spaces.txt
>>>>> svn: Commit failed (details follow):
>>>>> svn: '/svn/!svn/bc/1101/test/folder%202/file' path not found
>>
>> Yes, that's a bug.  I can reproduce it with trunk@HEAD.  Please raise
>> an issue.
> 
> I think we should change our test suite to use folder and file names
> containing spaces all the time.
> 
> For a start, we can easily add a space into the WC root abspaths used by
> all the tests:
> 
> [[[
> Index: subversion/tests/cmdline/svntest/main.py
> ===================================================================
> --- subversion/tests/cmdline/svntest/main.py	(revision 959554)
> +++ subversion/tests/cmdline/svntest/main.py	(working copy)
> @@ -178,7 +178,7 @@
>  # Where we want all the repositories and working copies to live.
>  # Each test will have its own!
>  general_repo_dir = os.path.join(work_dir, "repositories")
> -general_wc_dir = os.path.join(work_dir, "working_copies")
> +general_wc_dir = os.path.join(work_dir, "working copies")
>  
>  # temp directory in which we will create our 'pristine' local
>  # repository and other scratch data.  This should be removed when we
> ]]]
> 
> With that particular global change, the tests all still pass!  (I was
> slightly surprised.)
> 
> Any objection to this step?  The only down side I can think of is the
> slight inconvenience for us developers of having to quote the path on
> the command line when debugging the tests, and that's not something that
> should put us off.
> 
> Then we can work on extending the principle in one or more different
> ways, which, I'm sure, will detect a bunch of bugs:
> 
>   * space in some of the within-WC paths;
> 
>   * other ASCII pathnames that require URI-escaping, or in any other way
> have the potential to be mis-handled by Subversion;
> 
>   * non-ASCII characters (but the ability to do this would depend on
> what locales the test platform supports, and so would require
> configuration magic to enable it);
> 
>   * similar things for repository-side paths.
> 
> - Julian
> 
> 


-- 
C. Michael Pilato <cm...@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Stefan Sperling <st...@elego.de>.

On Mon, Jul 05, 2010 at 08:08:19PM +0200, Onno van der Straaten wrote:
> I think I should be able to take most steps using INSTALL file, the
> community guide, the Python test files as examples. There is one thing
> not clear to me at this point. The path not found problem is related
> to the http/https scheme. How does that work in the test suite? A test
> that reproduces the path not found problem would require an Apache
> server instance running somewhere? Are there Python examples of tests
> that use the http/https access layer?

You can run the entire test suite over different protocols.
See subversion/tests/cmdline/README

Stefan

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Onno van der Straaten <on...@gmail.com>.

I think I should be able to take most steps using INSTALL file, the
community guide, the Python test files as examples. There is one thing
not clear to me at this point. The path not found problem is related
to the http/https scheme. How does that work in the test suite? A test
that reproduces the path not found problem would require an Apache
server instance running somewhere? Are there Python examples of tests
that use the http/https access layer?

Onno

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Stefan Sperling <st...@elego.de>.

On Mon, Jul 05, 2010 at 10:33:13AM +0200, Onno van der Straaten wrote:
> Hi Stefan,
> Sure, this is something that I'm willing to try.
> 
> It is not a coincidence that I stumbled onto this '"corner case", I think.
> For this task I'm currently working on I'm probably stretching Subversion
> beyond it's intended use. To give you an idea: I'm using a script to prepare
> a massive commit that affects several thousands files. This commit is
> intended to cleanup a repository of a large project (+- 90 people) that have
> been committing changes for a few years, with little
> training/guidance/direction/control.
> 
> It seemed like a good idea at the time to do the cleanup in one fine sweep
> (Subversion commit) in this running project. So what I now have is a Ruby
> script that I can run against a working copy that enforces several rules:
> naming, structure conventions, removes obsolete files, old files, backup
> files, duplicate files etc.

I don't think trying to do a lot of refactoring in a single commit
is a good idea. You won't get very far with this if you end up moving
things around a lot. In general, with the 1.6.x working copy model
you should do a commit and update of the entire working copy after
each move operation.

> If you can quickly give some pointers for adding such Python tests I'm
> willing to give it a go. For example: do I need to a development environment
> to build Subversion myself from the trunk?

Yes. You will need to submit patches against Subversion's trunk,
so you should also be able to build and test the trunk.
If you need help with this and the documentation isn't clear enough
(see the INSTALL file), just ask.

Depending on which development platform you are using, there are also
developer-friendly scripts that can help with building and/or testing
Subversion. But it's good practice not to rely on those from the start,
to help you get a good understanding of the build process.

> What documentation is relevant for this task?

See http://subversion.apache.org/docs/community-guide/
It has a section on the build and test system, but you may want
to read other sections too to get a feel for how things work
around here.

Stefan

Re: Testing with spaces in filenames/paths

Posted by Onno van der Straaten <on...@gmail.com>.

I probably made things more difficult than they needed to be. For
example apr and apr-util was already installed with Apache2 I think,
I'm not sure. Anyway, finally success with the following configure

./configure --with-apr=/usr/bin/apr-config
--with-apr-util=/usr/bin/apu-config --with-apxs="/usr/bin/apxs2"
--disable-mod-activation --with-serf=/usr/local/serf

svn --version now also shows
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
  - handles 'http' scheme
  - handles 'https' scheme

Cool!
Onno

Re: Testing with spaces in filenames/paths

Posted by Stefan Sperling <st...@elego.de>.

On Tue, Jul 06, 2010 at 04:43:26PM +0200, Onno van der Straaten wrote:
> Now the make step fails with
> /home/ostraaten/subversion_export/subversion/libsvn_subr/.libs/libsvn_subr-1.so:
> undefined reference to `apr_hash_do'
> collect2: ld returned 1 exit status
> make: *** [subversion/svn/svn] Error 1
> 
> I think I'm doing the configure step wrong, this is what I now have
> ./configure --with-apr=/home/ostraaten/apr/apr-1.4.2
> --with-apr-util=/home/ostraaten/apr/apr-util-1.3.9
> --with-apxs="/usr/bin/apxs2" --disable-mod-activation
> --with-serf=/usr/local/serf
> 
> with-apr and with-apr-util is probably incorrect but at the moment is
> the only values I found would run. I tried to use my apache2 and the
> installed apr lib (/usr/local/apr/lib) but that wouldn't run.
> 

Try installing libapr-dev and libaprutil-dev packages.
Then you can run:

 ./configure --with-apr=/usr --with-apr-util=/usr
 --with-apxs="/usr/bin/apxs2" --disable-mod-activation
 --with-serf=/usr/local/serf

Maybe the same for serf, if your distribution has serf packages.

Having a single instance of the APR library on your system and
using it to build SVN makes things a lot simpler.

Stefan

Re: Testing with spaces in filenames/paths

Posted by Onno van der Straaten <on...@gmail.com>.

Now the make step fails with
/home/ostraaten/subversion_export/subversion/libsvn_subr/.libs/libsvn_subr-1.so:
undefined reference to `apr_hash_do'
collect2: ld returned 1 exit status
make: *** [subversion/svn/svn] Error 1

I think I'm doing the configure step wrong, this is what I now have
./configure --with-apr=/home/ostraaten/apr/apr-1.4.2
--with-apr-util=/home/ostraaten/apr/apr-util-1.3.9
--with-apxs="/usr/bin/apxs2" --disable-mod-activation
--with-serf=/usr/local/serf

with-apr and with-apr-util is probably incorrect but at the moment is
the only values I found would run. I tried to use my apache2 and the
installed apr lib (/usr/local/apr/lib) but that wouldn't run.

Onno

Re: Testing with spaces in filenames/paths

Posted by Stefan Sperling <st...@elego.de>.

On Tue, Jul 06, 2010 at 03:03:02PM +0200, Onno van der Straaten wrote:
> Hi Stefan,
> apxs was not installed on my machine but I installed it (I think) using
> sudo apt-get install apache2-threaded-dev
> 
> After that I can pass
> --with-apxs="/usr/bin/apxs2" to configure
> 
> But then the sudo make install file fails with
> apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
> apxs:Error: At least one `LoadModule' directive already has to exist..
> 

You should pass --disable-mod-activation to subversion's configure
script. The build system is trying to modify your existing apache2
installation to load the mod_dav_svn you installed. I'd recommend
configuring apache manually instead. Allowing the Subversion build
to tweak configuration files in /etc is a bad idea, because it can
interfere with your existing Apache setup, and with the way your
distribution is managing /etc.

Stefan

Re: Testing with spaces in filenames/paths

Posted by Onno van der Straaten <on...@gmail.com>.

Hi Stefan,
apxs was not installed on my machine but I installed it (I think) using
sudo apt-get install apache2-threaded-dev

After that I can pass
--with-apxs="/usr/bin/apxs2" to configure

But then the sudo make install file fails with
apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..

I tried to fix this myself (using Google) for example by adding
    # Dummy LoadModule directive to aid module installations
    #LoadModule dummy_module /usr/lib/apache2/modules/mod_dummy.so
to /etc/apache2/httpd.conf. That didn't work. Same message.

I also tried steps described in
http://subversion.wandisco.com/blogs/compiling-subversion-169-from-source-on-debian-lenny-fsfs-backend-apache2-bug-workaround.html
but that also didn't work. I was btw not sure about some of the steps
in that article. For example touch
/etc/apache2/mods-available/dav_svn.conf.
I created such a file, an empty one and then restarted apache2. Still
didn't work. Still same message.

Onno

Re: Testing with spaces in filenames/paths

Posted by Stefan Sperling <st...@elego.de>.

On Tue, Jul 06, 2010 at 12:09:51PM +0200, Onno van der Straaten wrote:
> I'm trying to build the 1.7 client from the trunk using the INSTALL
> file. I think I passed all steps, I did not see any errors/problems.
> Svn version shows the 1.7 version. This seems to work find except for
> that last message _mcleanup: gmon.out: Permission denied. Can I ignore
> that message?
> 
> A bigger problem is that not all of the RA modules are available,
> especially the module for the http/https scheme is missing, which is
> the one I want to use for my test. I think I have all the required
> bits installed so this is probably just a configuration problem? In
> the INSTALL file there is some relevant info
> 
> I'm not sure about $LD_LIBRARY_PATH.
> 
> I tried /usr/local/apr/lib
> export LD_LIBRARY_PATH=/usr/local/apr/lib
> and
> sudo ldconfig

That updates the run-time linker cache with references to /usr/local/apr/lib.
You may not want libraries from /usr/local/apr/lib in your system-wide linker
cache, because the could interfere with other programs linked to APR from
system packages.  If you start getting random segfaults in applications
using APR, this might be what caused it.

> But that doesn't fix the problem. What am I doing wrong?

You need to pass --with-apxs="/usr/bin/apxs" to configure.
Check the file config.log for errors related to apxs if this doesn't
help. Quite possibly you need httpd development support files installed,
which may be packaged separately from the actual web server depending
on your variant of UNIX.

Stefan

Re: Testing with spaces in filenames/paths

Posted by Onno van der Straaten <on...@gmail.com>.

I'm trying to build the 1.7 client from the trunk using the INSTALL
file. I think I passed all steps, I did not see any errors/problems.
Svn version shows the 1.7 version. This seems to work find except for
that last message _mcleanup: gmon.out: Permission denied. Can I ignore
that message?

A bigger problem is that not all of the RA modules are available,
especially the module for the http/https scheme is missing, which is
the one I want to use for my test. I think I have all the required
bits installed so this is probably just a configuration problem? In
the INSTALL file there is some relevant info

I'm not sure about $LD_LIBRARY_PATH.

I tried /usr/local/apr/lib
export LD_LIBRARY_PATH=/usr/local/apr/lib
and
sudo ldconfig

But that doesn't fix the problem. What am I doing wrong?
Thanks and Regards,
Onno

ostraaten@ostraaten-lenovo-laptop ~/subversion_export $ svn --version
svn, version 1.7.0 (dev build)
   compiled Jul  6 2010, 11:39:20

Copyright (C) 2010 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

_mcleanup: gmon.out: Permission denied
ostraaten@ostraaten-lenovo-laptop ~/subversion_export $

>From the INSTALL file
      Since the resulting binary depends on shared libraries, the
      destination library directory must be identified in your
      operating system's library search path. That is in either
      /etc/ld.so.conf or $LD_LIBRARY_PATH for Linux systems and in
      /etc/rc.conf for FreeBSD, followed by a run of the 'ldconfig'
      program. Check your system documentation for details. By
      identifying the destination directory, Subversion will be able
      to dynamically load repository access plugins.  If you try to do
      a checkout and see an error like:

      subversion/libsvn_ra/ra_loader.c:209: (apr_err=170000)
      svn: Unrecognized URL scheme
'https://svn.apache.org/repos/asf/subversion/trunk'

      It probably means that the dynamic loader/linker can't find all
      of the libsvn_* libraries.

Re: Testing with spaces in filenames/paths

Posted by Onno van der Straaten <on...@gmail.com>.

I'm trying to build the 1.7 client from the trunk using the INSTALL
file. I think I passed all steps, I did not see any errors/problems.
Svn version shows the 1.7 version. This seems to work find except for
that last message _mcleanup: gmon.out: Permission denied. Can I ignore
that message?

A bigger problem is that not all of the RA modules are available,
especially the module for the http/https scheme is missing, which is
the one I want to use for my test. I think I have all the required
bits installed so this is probably just a configuration problem? In
the INSTALL file there is some relevant info

I'm not sure about $LD_LIBRARY_PATH.

I tried /usr/local/apr/lib
export LD_LIBRARY_PATH=/usr/local/apr/lib
and
sudo ldconfig

But that doesn't fix the problem. What am I doing wrong?
Thanks and Regards,
Onno

ostraaten@ostraaten-lenovo-laptop ~/subversion_export $ svn --version
svn, version 1.7.0 (dev build)
   compiled Jul  6 2010, 11:39:20

Copyright (C) 2010 The Apache Software Foundation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.apache.org/

The following repository access (RA) modules are available:

* ra_svn : Module for accessing a repository using the svn network protocol.
  - handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
  - handles 'file' scheme

_mcleanup: gmon.out: Permission denied
ostraaten@ostraaten-lenovo-laptop ~/subversion_export $

Re: Testing with spaces in filenames/paths

Posted by Philip Martin <ph...@wandisco.com>.

Onno van der Straaten <on...@gmail.com> writes:

> Working on this task I have found three issues with Subversion. The path not
> found is a show stopper for me, I still need to find a workaround for that.

One workaround is to build a 1.7 client from Subversion trunk and use
that.  A workaround for Subversion 1.6 is to use file:// or svn://
instead of http://.

-- 
Philip

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Onno van der Straaten <on...@gmail.com>.

Hi Stefan,
Sure, this is something that I'm willing to try.

It is not a coincidence that I stumbled onto this '"corner case", I think.
For this task I'm currently working on I'm probably stretching Subversion
beyond it's intended use. To give you an idea: I'm using a script to prepare
a massive commit that affects several thousands files. This commit is
intended to cleanup a repository of a large project (+- 90 people) that have
been committing changes for a few years, with little
training/guidance/direction/control.

It seemed like a good idea at the time to do the cleanup in one fine sweep
(Subversion commit) in this running project. So what I now have is a Ruby
script that I can run against a working copy that enforces several rules:
naming, structure conventions, removes obsolete files, old files, backup
files, duplicate files etc.

There are similarities between what I'm doing with Ruby and what you are
doing with Python I think. Because the cleanup operation is so massive I
decided to automate it using Ruby. You could say I have created a simple
Ruby model layer on top of the Subversion command line client to help define
and apply the cleanup rules. Just a simple example to give you an idea: I
can find a folder and af file in my working copy by basename
f, d = Document.find_by_basenames('some_folder', 'some_file')
and then move the document to that folder
d.move(f)

Working on this task I have found three issues with Subversion. The path not
found is a show stopper for me, I still need to find a workaround for that.

If you can quickly give some pointers for adding such Python tests I'm
willing to give it a go. For example: do I need to a development environment
to build Subversion myself from the trunk? What documentation is relevant
for this task?
Best Regards,
Onno

On Fri, Jul 2, 2010 at 1:45 PM, Stefan Sperling <st...@elego.de> wrote:

> On Fri, Jul 02, 2010 at 11:42:58AM +0100, Julian Foad wrote:
> > Any objection to this step?  The only down side I can think of is the
> > slight inconvenience for us developers of having to quote the path on
> > the command line when debugging the tests, and that's not something that
> > should put us off.
>
> -1
>
> I tend to find spaces in filenames I work with on the command line quite
> annoying. So I'd prefer explicit unit tests which check for whitespace
> within local paths and within URLs, much like what you listed below.
>
> Onno, do you have time and some rudimentary python skills (or time
> to pick those up)? If so, it would be great if you could contribute
> a couple of such tests (you could start slowly with just one test,
> get it reviewed and committed, and then do more if you want to).
> That would help us a lot in catching such bugs in the future.
>
> Thanks,
> Stefan
>
> > Then we can work on extending the principle in one or more different
> > ways, which, I'm sure, will detect a bunch of bugs:
> >
> >   * space in some of the within-WC paths;
> >
> >   * other ASCII pathnames that require URI-escaping, or in any other way
> > have the potential to be mis-handled by Subversion;
> >
> >   * non-ASCII characters (but the ability to do this would depend on
> > what locales the test platform supports, and so would require
> > configuration magic to enable it);
> >
> >   * similar things for repository-side paths.
> >
> > - Julian
> >
>

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Justin Erenkrantz <ju...@erenkrantz.com>.

On Fri, Jul 2, 2010 at 4:45 AM, Stefan Sperling <st...@elego.de> wrote:
> On Fri, Jul 02, 2010 at 11:42:58AM +0100, Julian Foad wrote:
>> Any objection to this step?  The only down side I can think of is the
>> slight inconvenience for us developers of having to quote the path on
>> the command line when debugging the tests, and that's not something that
>> should put us off.
>
> -1
>
> I tend to find spaces in filenames I work with on the command line quite
> annoying. So I'd prefer explicit unit tests which check for whitespace
> within local paths and within URLs, much like what you listed below.

+1.

For example, seeing the mu character in all of our tests would drive
me bonkers.  I don't see a reason why we can't have some explicit
tests which focus on ensuring the crazy paths are handled correctly,
but all of them?  Ugh.  -- justin

Re: Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Stefan Sperling <st...@elego.de>.

On Fri, Jul 02, 2010 at 11:42:58AM +0100, Julian Foad wrote:
> Any objection to this step?  The only down side I can think of is the
> slight inconvenience for us developers of having to quote the path on
> the command line when debugging the tests, and that's not something that
> should put us off.

-1 

I tend to find spaces in filenames I work with on the command line quite
annoying. So I'd prefer explicit unit tests which check for whitespace
within local paths and within URLs, much like what you listed below.

Onno, do you have time and some rudimentary python skills (or time
to pick those up)? If so, it would be great if you could contribute
a couple of such tests (you could start slowly with just one test,
get it reviewed and committed, and then do more if you want to).
That would help us a lot in catching such bugs in the future.

Thanks,
Stefan

> Then we can work on extending the principle in one or more different
> ways, which, I'm sure, will detect a bunch of bugs:
> 
>   * space in some of the within-WC paths;
> 
>   * other ASCII pathnames that require URI-escaping, or in any other way
> have the potential to be mis-handled by Subversion;
> 
>   * non-ASCII characters (but the ability to do this would depend on
> what locales the test platform supports, and so would require
> configuration magic to enable it);
> 
>   * similar things for repository-side paths.
> 
> - Julian
>

Re: Testing with spaces in filenames/paths

Posted by Philip Martin <ph...@wandisco.com>.

Julian Foad <ju...@wandisco.com> writes:

> --- subversion/tests/cmdline/svntest/main.py	(revision 959554)
> +++ subversion/tests/cmdline/svntest/main.py	(working copy)
> @@ -178,7 +178,7 @@
>  # Where we want all the repositories and working copies to live.
>  # Each test will have its own!
>  general_repo_dir = os.path.join(work_dir, "repositories")
> -general_wc_dir = os.path.join(work_dir, "working_copies")
> +general_wc_dir = os.path.join(work_dir, "working copies")
>  
>  # temp directory in which we will create our 'pristine' local
>  # repository and other scratch data.  This should be removed when we
> ]]]
>
> With that particular global change, the tests all still pass!  (I was
> slightly surprised.)

You changed the path outside the working copy so it's not something
Subversion passes that to the server.  With that change you are mostly
testing the shell quoting of the testsuite.

-- 
Philip

Testing with spaces in filenames/paths [was: Space in filename causes path not found on commit]

Posted by Julian Foad <ju...@wandisco.com>.

Philip Martin wrote:
> >>> Adding folder 1/file with spaces.txt
> >>> svn: Commit failed (details follow):
> >>> svn: '/svn/!svn/bc/1101/test/folder%202/file' path not found
> 
> Yes, that's a bug.  I can reproduce it with trunk@HEAD.  Please raise
> an issue.

I think we should change our test suite to use folder and file names
containing spaces all the time.

For a start, we can easily add a space into the WC root abspaths used by
all the tests:

[[[
Index: subversion/tests/cmdline/svntest/main.py
===================================================================
--- subversion/tests/cmdline/svntest/main.py	(revision 959554)
+++ subversion/tests/cmdline/svntest/main.py	(working copy)
@@ -178,7 +178,7 @@
 # Where we want all the repositories and working copies to live.
 # Each test will have its own!
 general_repo_dir = os.path.join(work_dir, "repositories")
-general_wc_dir = os.path.join(work_dir, "working_copies")
+general_wc_dir = os.path.join(work_dir, "working copies")

 # temp directory in which we will create our 'pristine' local
 # repository and other scratch data.  This should be removed when we
]]]

With that particular global change, the tests all still pass!  (I was
slightly surprised.)

Any objection to this step?  The only down side I can think of is the
slight inconvenience for us developers of having to quote the path on
the command line when debugging the tests, and that's not something that
should put us off.

Then we can work on extending the principle in one or more different
ways, which, I'm sure, will detect a bunch of bugs:

  * space in some of the within-WC paths;

  * other ASCII pathnames that require URI-escaping, or in any other way
have the potential to be mis-handled by Subversion;

  * non-ASCII characters (but the ability to do this would depend on
what locales the test platform supports, and so would require
configuration magic to enable it);

  * similar things for repository-side paths.

- Julian