Added and Removed Files/Directories

Out of experience I knew that it was necessary to “register” and “deregister” files at subversion before it can do its “magic”. To be more precise, there are commands for

• adding files/directories,
• removing files/directories and
• committing the changed state to the server (changed content of files is detected automatically during this call)

As the third bullet item did solve the problem of changed files, it opened up the “can of worms” for both new and deleted files. At first glance this appears to be more step back than forth. However, there is support for this situation: the command line tool svn allows to provide details about the current state of the files. One may call svn status to query for a list of changes made locally. For each file the name and its status is printed. For example the values “?” indicates that a file (or directory) is available locally, but has not been uploaded/added to the list of files to add on the next commit to the server. Similarly, the “!” indicates that a file has been deleted locally, but the deletion has not been queued to be sent to the server yet.
The resolution of this matter was a simple batch file which looks as follows (derived from svnautocommit):

for /f "tokens=2*" %%i in ('svn status %1 ^| find "?"') do svn add "%%i %%j"
for /f "tokens=2*" %%i in ('svn status %1 ^| find "!"') do svn delete "%%i %%j"

(whereas %1 denotes the directory where the local copy is being stored) To state it already right out of the box: This isn’t the most efficient way of doing so, but in my case it already did the job. Adding the command

svn commit -m "Automatic Commit" %1

afterwards around enabled this batch file to be executed automatically with the help of Windows Task Scheduler.

Adoption to the Usecase and Long Lasting Commits

Having figured out this part of theory, I sprang into action: It ever rankled me that I did not copy the data “out” of the WinS server. As stated before the backup data was stored on a DVD+RW, but this media had to always remain in the drive at the server system (for the next backup). A better approach is to make sure that the data leaves the system and gets copied to some foreign location (in case of fire ideally this would also be another room / location which is not possible in my case, but even using another computer at least is better than nothing). Seeing a chance to change that I installed an Apache Webserver plus the subversion server package on the LinS. On the WinS I installed the Subversion command line tool and uploaded the data to backup from the WinS to the LinS (it would have been better to use the svn import command, though I used the svn add command). During this activity I hit another unexpected problem: When apparently preparing to upload a large file to the HTTP repository during executing the svn commit command, the client (here, the WinS) required some time to calculate the difference which should be sent to the Subversion server via the Apache Webserver. In my case, however, the KeepAlive option of the webserver was enabled in /etc/httpd/httpd.conf (which is a good idea as such), but the KeepAliveTimeout parameter there was set to 15 seconds. If the client took more than this leap time to send the next file to the server, the webserver closed the connection (due to this KeepAlive timeout) which in turn caused the client to quit uploading with a cryptic error message. I came to this idea when I thought about this behaviour having read through this article. In my case I changed the standard value for KeepAliveTimeout from 15 seconds to 150 seconds which did the trick – since then I never experienced commit stops anymore. Please note that this might be a bad idea, if your webserver also serves “real clients” such as normal web pages – in my scenario almost the sole purpose of the webserver is to deal with the Subversion requests, so I could make that change globally without risking anything.