svn post-commit hook : “error resolving case” & “skipped \\ip-address\users\myDir”" messages

Question

I've got Collabnet SVN server installed on windows. Additionally, I have implemented a post-commit hook that should update a working copy "B" of a project when I commit to the repository from a working copy "A". Working copy "B" resides on a network drive [H -> \\ip-address\users\myDirB ]:

• Now when I specify the line of code below, in my post-commit hook and commit a change-set from working Copy "A":

SET WORKING_COPY=H:/myDirB

I get the error: svn post-commit hook: "error resolving case"

• Alternatively if I specify: SET WORKING_COPY=//ip-address/users/myDirB

I get the error:

"skipped \ip-address\users\myDirB""

What am I doing wrong? Cheers.

Please note: * Collabnet Subversion server is installed on my C: drive

• it's running as a service account with full privileges over the network directory I want to update automatically via the post-commit hook ie - \\ip-address\users\myDirB*

• I also have the path \\ip-address\users\myDirB mapped on to H: drive

Answer 1

SET WORKING_COPY=//ip-address/users/myDirB

can not work, since cmd.exe needs a plain path (drive letter, colon, relative path). It can not deal with other paths like UNC or ip addresses. It must have a drive letter.

SET WORKING_COPY=H:/myDirB

this however doesn't work because you mapped H: to something as the user you're logged on. But the hook script is running as the user your svn server is running, ie as the service account. And the service account does not have the H: drive mapped.

Answer 2

I would recommend against using a post commit hook to do this. It's going to be forever brittle, and complicated - as you're finding out.

You should setup a continuous integration build that monitors the svn repo and then deploys the code if needed. Separating these concerns will save you headache in the future, provide easy way to notify team (IM, email or dashboard), and will help you out when/if wish to do any automated testing.

Answer 3

two issues I ran into were (1) paths and (2) permissions. Our old setup included collabnet subversion server 1.5.6 and apache 2.2 on Windows 2008 R2 (it's now wandisco 1.7.2 / apache2.2 on Win 2008 R2).

initially, I had the path as a mapped drive and the subversion and apache services running as the Local System account. So, we had something like:

SET WORKING_COPY=X:\the\path\to\theworkingcopy

Running it via CLI was fine, but commiting and executing via subsequent hook resulted in log message like

Error resolving case of 'X:\the\path\to\theworkingcopy'

So, I changed WORKING_COPY to use a UNC path such as:

\\servername\DRIVELETTER$\the\path\to\theworkingcopy

Still same problem, but I figured the services (for both) needed to run with network privileges, so I changed the service "Log On As" to a domain account for the svn server and apache.

One other issue I ran into was setting the domain for the services' "Log On As" user. I used a domain user, but used a wildcard for the domain, eg ".\theuser"

Then it just worked.

As far as this being a brittle solution, I'd agree that CI is a better way to go. Even though our svn update over UNC is (1) documented and (2) works now and (3) it's unlikely to change in the near future - as thekbb noted - it doesn't separate concerns.