Problem with the postcommit.bat file

Hi, This is only a problem if the server and the repository are based on different box, so I realise this is a limited problem. The postcommit.bat file A) depends on JAVA being installed on the repository box and B) assumes that the software was install on the repository box. I am work in a windows environment and due to "companies policy" I have installed the server on my box but due to the wish to have the repository backed up they have insisted that I have the repository on a network box (which I am not allowed to install the software). I would suggest that it should try to run the installation where the server is not just assume it will be on the local box. I know this throws up further issue so I leave it to you.    Ken Wood (mixer)

Last updated 11 years ago

The right thing to do would be to get a proper server installed & configured. If the the repository is important enough to be backed up, then it must be important enough to put on the correct hardware & software.  A desktop is not a server and even if we ignore all of the "annoying" problems like performance and your hooks needing modification, you've got major security & reliability issues here. What happens when your desktop goes offline because the power supply burned out? Or the cubicle farm network gets rewired into a new topology? Or when your desktop gets replaced? Or when you get replaced?  Hosting the repository on a network share accessed from the server is not a recommended configuration, and there are situations where it can be downright broken. I don't see value in uberSVN (or any other product) taking additional steps to encourage poor configuration practices.

Hi Andy,  In the ideal world I would push ahead as you suggest, unfortuantely it is not. I work for a very Microsoft based company, with security as a top priority (it is a bank). I am try to move the system I work on from sourcesafe to Subversion. I am the only person who is altering the system so having the server on my box is not an issue. The system I work on is crucial to the part of the bank I work on, hence they insist that the repository is backed up. They don't back up individuals boxes, hence I put the repository on a network drive.  So to the issue. The software does not warn/stop you putting the repository on a network drive. I only spotted the issue when looking in the hooks directory (on curiousity) and spotting a batch file (I having used subversion and written hook file for my last company) I investigated what it did. I was suprised that it assumed that JAVA was installed (as I don't have it installed even on my local box, and received no warning) and the server was on the same box.  So what does the jar file the batch file is calling doing? is it important?

mixer;117897In the ideal world I would push ahead as you suggest, unfortuantely it is not. I work for a very Microsoft based company, with security as a top priority (it is a bank). I am try to move the system I work on from sourcesafe to Subversion. I am the only person who is altering the system so having the server on my box is not an issue. The system I work on is crucial to the part of the bank I work on, hence they insist that the repository is backed up.[/quote]Your statements contradict each other. If security is a top priority, then your Subversion server should be on a server. If the system you're working on is crucial to the company, then your Subversion server should be on a server. If security is a top priority, you wouldn't even have been able to download uberSVN and install it on your desktop (I can't download it on my corporate network). If security is a top priority how are you able to subvert the use of VSS?    And I won't even start on the use of VSS anywhere that code loss isn't a top priority.    

mixer;117897The software does not warn/stop you putting the repository on a network drive.

And my car doesn't shut off at 100 miles per hour. That doesn't mean I should drive that fast.    There is definitely documentation online that indicates that a network share isn't an advisable configuration unless you take very specific steps.    [QUOTE=mixer;117897]I only spotted the issue when looking in the hooks directory (on curiousity) and spotting a batch file (I having used subversion and written hook file for my last company) I investigated what it did. I was suprised that it assumed that JAVA was installed (as I don't have it installed even on my local box, and received no warning) and the server was on the same box.

The uberSVN web interface is a Java application, so the presence of Java on the server should be a completely safe assumption when installed in a recommended/supported configuration.    If you aren't using uberSVN, why not just rename (to disable) the hook?