Hello,
I'm using Subversion in a windows shop. We have a FSFS repository that
we're accessing via XP's filesharing (file: URLs with UNC paths).
Company policy won't allow us to install ssh/sshd, or to run any new
services such as apache or svnserver as a deamon.
We have PSexec installed on our sv
>You should stop doing so immediately and set up a proper server. Any user
>with direct file:-protocol access to the repository can access any part of it
>(bypassing any path-based security you've put in place) and can even delete
>the entire repository (accidentally or intentionally).
What you ar
>Additionally, the Subversion development team has announced file://
>protocol should not be considered for production environments.
Reread OP then, I'm trying to get away from using a file:// URL, using
PSexec to execute svnserver.
Hello,
I've retrieved the /subversion-1.6.11 tarball from
http://subversion.tigris.org/downloads/subversion-1.6.11.tar.bz2 .
I can configure and build it with serf- eg
configure: serf library configuration
checking serf.h usability... yes
checking serf.h presence... yes
checking for serf.h... ye
Neon is required? The INSTALL that comes with 1.6.11 says that either
neon or serf will give http access:
* libneon or libserf (OPTIONAL for client)
The Neon and Serf libraries both allow the Subversion client
to send HTTP requests. ... Your client can be compiled against
Hi Campbell,
I can build a working binary as well, it's just that the client
doesn't have the http: method when built with only serf and
"--without-neon". It sounds like you're building it with neon in each
cases, just not using the "--with-neon" flag; omitting the flag makes
configure look for it
Just a stab in the dark, what version of Subversion do you have on
that box? It looks like this perl module comes bundles with Subversion
1.4 and some users have complained that it doesn't first check to see
if there is a subverison installed for it to use. It also looks like
that module was last u
