You're assuming the Web server is Apache.

Yes, both options were used. The user authentication information should already be cached... A colleague with server access can run svn export with the --config-dir option and it executes successfully without any prompts...

** EDIT **

Executing the exact same svn export command as the batch file (with the --non-interactive option)(and to be paranoid, my colleague's personal "%APPDATA%\Subversion" directory deleted), she is getting the same stderr output as the hook script.

** EDIT **

Without the --non-interactive option apparently it just sits there...

svn export --force --config-dir "directory" "file_url" "file_path" \ 1>"svn-stdout.txt" 2>"svn-stderr.txt"

** EDIT **

As an administrator, it executes fine.

** EDIT **

Actually, svn wasn't just sitting there... It was waiting for her to enter the password. The username/password prompt was being redirected to files...

You appear to be correct... I thought we already saved the user credentials, but apparently not... So we're doing it again now... I'm about to find out if it worked...

** EDIT **

Now the hook script fails and none of the stream files exist.

I don't even know if that's possible... The user has no logon, whatever that means...

Anyway, it seems that when I sent the latest revision of my program to replace the currently "installed" one I sent it with a .txt extension appended. My colleague forgot to rename it so the batch file wasn't able to find my program, which caused it to fail and no output to be captured... After correcting that, I got log messages indicating that svn exited with a non-zero exit status. When I left work I had just modified the program to capture svn's output. Tomorrow I'll see if that yields anything useful.

Just so we're clear, the only purpose of the C# program is to run svn export? And you are running the C# program from a batch file? If that is actually the case, then what you are doing is almost worse-than-failure-worthy.

On the topic of actually making the solution work: if it's asking for a user name and password, provide one. The commands are quite clearly shown in svn help export.

Just hide the .svn directories. Can't be that hard, no matter what you're using.

How about just do an svn update locally and then copy all the files that aren't named ".svn"?

It's pretty easy: you already have this:

So just takes those files, and copy them using the C# program, instead of using svn export. Maybe a mapped network drive, maybe FTP, maybe WebDAV, whatever you like.

Maybe you think that svn export can store the files on a remote destination? It can't.

I'm going to start from scratch. You have a subversion repository and a web server. These are on different machines. You need the web server to be updated when the subversion repository is updated.

I would solve this problem using a post-commit hook, like you are trying to do. The post commit hook obviously runs on the machine with the subversion repository.

The script should maintain a local copy of the repository (updated with svn update). When the script is executed, it should update the repository, then copy all of the files in the local repository to the remote server, ignoring the subversion special directories.

As an example, this would be the script, using lftp to send the files over unencrypted FTP.

cd C:\subversion\www_files
svn up
lftp ftp://user:password@host -e "mirror -nvR --delete -x \.svn . ."

This is based on a script I use to update a static HTML web site that uses a subversion repository to maintain its files. The script only updates files that have changed, as based on the time stamp and file size. The update process is slow if there are a large number of directories in the repository (lftp must look in each one on the remote server).

Well the server is running Windows Server and the Subversion server and Web server are both running on the same machine with "local access" to the repositories and document roots. I need a Windows solution and I'm pretty sure I was told that Cygwin-/MSYS-like tools are not an option.

No, I hadn't. It works fine with a file:/// url. Why isn't this a solution to use in the long-term though? Am I missing something?

Currently, I'm using subversion export with a file repository URL (file:///) and a local path (<tt><DriveLetter>:</tt>). Is there anything particularly wrong with it (i.e. security holes or performance)?

The svn up idea does sound better, but it would still need a wrapper of some sort to send particular branches to particular web roots (i.e. current development branch, current testing branch) automatically when they are committed. As is, a simple configuration file is used that matches branches to web roots... That was pretty much why I moved it into a C# program.

Have you tried saving the users in a file and then redirect stdin to the execution command?

svn .... < bleh.txt

i do this process/stdin stuff all the time with just plain C.