Subversion 1.5 WebDAV Write-Thru Proxies

Yesterday at the Pre-SubConf Subversion Workshop in Munich, I presented a short bit about a new Subversion 1.5 feature — WebDAV write-thru proxy support. This feature allows for a Subversion server deployment based around Apache 2.2.x and mod_proxy in which there is a single master server and associated repository, and one or more slave servers which handle read operations while passing through (proxying) write operations to that single master server. In this deployment scenario, each slave server has its own copy of the master repository which is kept in sync by some process, typically one driven by hook scripts on the master server itself.

Why might someone want to use such an arrangement? Well, users are far more likely to be doing read operations (such as checkouts, updates, status checks, log history requests, diff calculations, etc.) than write operations (such as commit, revision property changes, and lock/unlock requests). You might wish to employ several servers to share the burden of handling those read requests (a load-balancing scenario). Or perhaps you have a worldwide organization (such as CollabNet’s) with offices in, say, the United States, Eastern Europe, and India. If you deploy a single centralized server across the whole organization, you will almost certainly wind up favoring some users over others in terms of the performance of the network links between them and the Subversion server. WebDAV write-thru proxies would allow you to keep geographically local slave servers for each of your global regions, universally optimizing the performance of all of your users’ read requests.

For the purposes of my presentation, I whipped up a simple WebDAV write-thru proxy scenario with a single slave server, and using svnsync as the mechanism for propogating changes from the master server to the slave server. The following describes how you can do the same.

First, you’ll need to have Apache HTTP Server on your master and slave servers, and on the slaves it must be version 2.2.0 or better with mod_proxy enabled. Now, you’ll need to configure your master server to expose your repository. Assuming your Subversion repository is located at /opt/svn/project, you might do so by adding a block like this to its httpd.conf file:

<Location /svn/project>
   DAV svn
   SVNPath /opt/svn/project
</Location>

Your slave servers will each eventually have full replicas of the master server’s repository (which we’ll take care of in a bit), but at this point will need at least some httpd.conf magic to expose their replica (which, again, we’ll assume lives at /opt/svn/project):

<Location /svn/project>
   DAV svn
   SVNPath /opt/svn/project
   SVNMasterURI http://IP-ADDR-OF-MASTER/svn/project/
</Location>

Notice that SVNMasterURI directive — that’s the bit that’s new to Subversion 1.5. It tells the slave server to proxy write-type operations to the master machine, and provides the URL at which the master machine’s repository can be found.

Now, there’s a second bit of httpd.conf configury we need on each slave. Remember that we’re planning to use svnsync to push changes from the master to the slave servers. Well, svnsync does so using regular commits, and if we’re proxying commits back to the master server, that won’t work out so well. So we add another Location block which exposes the server’s repository, but which does not proxy write operations through, and which allows commits only from the master server’s IP address:

<Location /svn/project-proxy-sync>
   DAV svn
   SVNPath /opt/svn/project
   Order deny,allow
   Deny from all
   Allow from IP-ADDR-OF-MASTER <Location /svn/project>

Okay, let’s talk about the actual repositories. As I mentioned, each slave server needs a replica of the master repository. And for our purposes, that replica needs to be initialized as a read-only mirror of the master repository by svnsync. (See this blog post for some basic information about using svnsync.) You’ll run svnsync init from the master server, and for the sake of performance (which is critical in this scenario), you’ll do so using file:/// access to the master. The cautious among you will simply use svnadmin create (or the equivalent in some third-party Subversion tool) to create a new repository on each slave, create for it a permissive pre-revprop-change hook, then use svnsync init http://IP-ADDR-OF-SLAVE/svn/project-proxy-sync file:///opt/svn/project (notice we’re syncing via our special sync URL), and finally use svnsync sync http://IP-ADDR-OF-SLAVE/svn/project-proxy-sync to copy each revision from the master to the slave. Those of you who are more adventurous will find every way possible to shortcut this process, from creating just one slave’s svnsync-ready mirror repository and literally copying that to every other slave, to even optimizing out that sync job cost by hand-editing the revision 0 properties on literal copies of the master repository. I’ll leave such trickery as an exercise to the reader.

Let’s see where we are. We have servers with Apache HTTP Server configured. We have repositories in place on each machine, where the slave repositories are svnsync-ready mirrors of the master. Now we need the automation bits which keep those mirrors in sync. We do this using the master repository’s hook subsystem. If you plan to allow revision property changes, you’ll need a permissive pre-revprop-change hook script on the master repository, and then also a post-revprop-change hook which tells svnsync to re-copy revision properties for a given revision when one of that revision’s properties is changed:

#!/bin/sh
REVISION=${2}
# Launch (backgrounded) sync jobs for each slave server.
svnsync copy-revprops http://IP-ADDR-OF-SLAVE1/svn/project-proxy-sync ${REVISION} &
svnsync copy-revprops http://IP-ADDR-OF-SLAVE2/svn/project-proxy-sync ${REVISION} &
svnsync copy-revprops http://IP-ADDR-OF-SLAVE3/svn/project-proxy-sync ${REVISION} &

You’ll also need a post-commit hook to transfer new revisions in full to the slaves:

#!/bin/sh
# Launch (backgrounded) sync jobs for each slave server.
svnsync sync http://IP-ADDR-OF-SLAVE1/svn/project-proxy-sync &
svnsync sync http://IP-ADDR-OF-SLAVE2/svn/project-proxy-sync &
svnsync sync http://IP-ADDR-OF-SLAVE3/svn/project-proxy-sync &

Why are we backgrounding our svnsync processes? As I mentioned, performance is critical here. Every second that our slaves remain out of sync with the master is a second in which the user who performed the commit or revision property change might try to then perform a read operation (like svn update) against that revision. If he does so, he’ll get an error that indicates that the revision doesn’t exist on the server, which while not fatal is at the very least quite confusing.

At this point, we could go live with our servers and things would mostly work. Users would checkout working copies from one of the available slave servers. When they performed read operations against that repository, the server would field the requests from its replica of the master repository. When they did commits or changed revision properties, their slave server would hand off to the master server, which would do the real work and then propogate those changes back out to all the slaves. But there are some additional things you may want to configure before going live.

First, we never added any authentication or authorization stuff for our users. Interestingly, you’ll need the authentication stuff to match across all servers (and need to rig up a way to keep those in sync), but you need only the read-authorization stuff on the slaves, and both the read- and write-authorization stuff on the master. (It’s probably easiest just to keep all that stuff in sync across all the servers.)

Secondly, we didn’t do anything to handle lock/unlock client requests. To do so properly requires implementing post-lock and post-unlock hook scripts on the master which in turn perform the lock/unlock operations on each slave as the user doing the locking/unlocking. This is complicated work. Fortunately, if you choose to omit it, lock enforcement in your deployment scenario should still work. It’s just that lock queries (asking, "What’s locked, and by whom?") will always turn up empty.

Finally, we didn’t do anything to handle the problems that might occur if the link between the master and a slave server should go down at the wrong time. If the link drops during some client commit operation, that’s okay — the commit will never finish on the master server, and the user will hear back from his/her slave server that something went wrong. At worst the commit will complete on the master but the user’s client will never know about it. (This same thing can happen in a single-server setup if the link falls down while the server is trying to respond to the final commit MERGE request.) If the link drops during the svnsync phase after a commit, that slave server will continue to work, but might be out of sync until the next commit. You could implement a cron job on the master that occasionally syncs all the slave repositories to minimize that out-of-sync period. What about svnsync failing after a revision property change? That’s more complex — you may need to implement some wrapper around that process that can reliably track success and failure and provide a retry mechanism. That’s true also of something failing while trying to propogate lock/unlock status to the slave servers.

As you can see, the state of the art is currently not such that you flip a switch and suddenly wind up with a one-master-to-many-slaves repository replication deployment scenario. It’s tricky business, fraught with opportunities to make mistakes and to leave edge-cases uncovered. But this new feature in Subversion 1.5 provides the fundamental requirements if you’re willing to see the complexities through to completion.

C. Michael Pilato

C. Michael Pilato is a core Subversion developer, co-author of Version Control With Subversion (O'Reilly Media), and the primary maintainer of ViewVC. He works remotely from his home state of North Carolina as a software engineer for CollabNet, and has been an active open source developer since early 2001. Mike is a proud husband and father who loves traveling, soccer, spending quality time with his family, and any combination of those things. He also enjoys composing and performing music, and harbors not-so-secret fantasies of rock stardom. Mike has a degree in computer science and mathematics from the University of North Carolina at Charlotte.

Tagged with: , , , , , , , , ,
Posted in Subversion
48 comments on “Subversion 1.5 WebDAV Write-Thru Proxies
  1. Matt Doar says:

    This is going to be very useful, thanks. Is anyone using it with a sizeable repository yet? Any feedback about how it works – latency, unexpected problems etc.

  2. Mark Keisler says:

    Thanks, Mike. The on problem that I have is that backgrounding the svnsync in the post-commit hook does not keep the client from waiting until the svnsync operation has completed. The client sits at “Transmitting file data” until the svnsync is done. I call a script from post-commit that is backgrounded and that script does the svnsync command which is also backgrounded. Am I missing something?

  3. Matt – 1.5 is not released yet, so while there is at least one person that has been using this in a patched version of 1.4, it has not been used widely enough yet to have that information.
    Mark – you have to do some trickery to get hooks to return immediately and let the process run in the background. See this thread from the mailing list which has an example:
    http://svn.haxx.se/users/archive-2006-08/0925.shtml

  4. Eric Gillespie says:

    Right, the & is not enough; you also need to close stdout and stderr like:
    svnsync copy-revprops http://IP-ADDR-OF-SLAVE1/svn/project-proxy-sync ${REVISION} > /dev/null 2>&1 &
    or with something like this:
    LOG=$(mktemp /tmp/pre-revprop-change.XXXXXX)
    exec > ${LOG}
    exec 2>&1
    [hook body]
    mail -es “REVPROPCHANGE $*” somewhere < ${LOG}
    rm -f ${LOG}

  5. Blair Zajac says:

    Mike,
    The article says Apache 2.2.x, but I don’t see any ifdefs in mod_dav_svn.c limiting it to that version. Will this work with Apache 2.0.x? If not, what will happen when somebody tries to use it on 2.0.x?
    Thanks,
    Blair

  6. Good question. I recall when Justin committed the feature that it required some fixes in mod_proxy and it was only done in 2.2. It seems like we ought to reject the directive if it is used in 2.0.x. You should probably file an issue for this though, not enter it here.

  7. Prakhar says:

    SVN 1.5 will be very useful for the scenario I am having. Can we use master slave using VPN connection, because I don’t have leased lines and servers are sitting in different countries? Also how frequently slave gets updated?

  8. C. Michael Pilato says:

    Prakhar:
    Subversion defers matters of network traffic routing to lower level processes. If your master and slave machines share a VPN connection, and you can transmit HTTP/WebDAV traffic back and forth across that connection, then I know of no reason why you couldn’t establish a WebDAV proxy deployment using that VPN.
    As for how frequently the slave gets update, that’s entirely up to you. I would recommend having the master’s post-commit and post-revprop-change hook scripts fire off synchronizations, and *also* have a cron job that runs every so many hours to do the same (just in case the most recent hook-fired sync job goes awry and there’s not been more commit activity on the master).

  9. Manish Baxi says:

    Mike
    We are planning to upgrade from 1.4 to 1.5 as soon as 1.5 is released for general usage. I went through your article and decided to try out 1.5 on a set of Windows sandboxes. First up, the current set of Windows binaries does not seem to have svnsync.exe. I was therefore unable to test out the whole set up. Will you be able to check this and let me know where I can download a reliable version of svnsync.exe from?
    Next, I wanted to validate a few things with you. Our teams predominantly consist of developers (as I guess most software teams would). We encourage our developers to check-in at least once a day and if possible multiple times a day to prevent their local copies from getting out of sync with the repository (as long as the code compiles locally). This practice means that most people on our teams (developers) perform a write (commit) almost as frequently as they peform reads (checkouts and updates). I personally commit at least four to five times a day but update only once a day. As of now this is just a train of thoughts I have. I am going to verify this from Apache logs on our current system. However, do you feel that given our scenario, using write-through proxy set up will really help too much?
    We are geographically distributed across seven countries and many different offices. Right now what hits our teams the most is network latency rather than anything else. I am not sure if the write-through proxy feature will really take away the problems associated with network latency (especially since half the operations are write operations anyway). What are your thoughts on this?

  10. Manish Baxi says:

    Actually, one more question. Instead of using SVNPath, can we use SVNParentPath in configuration files? I tried using SVNParentPath but no proxing seems to be happening, i.e. commits made to the slave are made in the slave repository only.
    Per repository configuration will be quite painful.

  11. Manish, I believe you can use SVNParentPath so long as your repository locations on the master and server end with the same basename, and your SVNMasterURI configuration doesn’t carry that basename. I think the proxy code is going to use SVNParentPath + /basename to find the repository on the slave, and SVNMasterURI + /basename to address the repository on the master. (There’s a mailing list post which corroborates this at: http://svn.haxx.se/users/archive-2008-02/0326.shtml)
    As for whether or not this whole setup is wise in your situation, I really can’t say. Maybe something more complex, like a proxy setup with a follow-the-sun type of rotating master would work out better (read “lots of custom coding” or “check out WANDisco”). Or maybe you could go the multi-master route using geo-local read-write repositories which themselves are svk mirrors of The One Repository. Everybody’s needs and environment are different — you may have to just try some of these things out to see what works best for you and your teams.

  12. Craig Menke says:

    Mike,
    We are in the middle of converting to SVN along with many other changes which has caused some headaches for our team. The main issue we are having at this time is our Master Repo’s IP has recently been changed (due to conversion to virtual machines), and now our SVNSYNC obviously does not work. Could you recommend anything other than blowing away our current mirrors and recreating those?
    Thanks for any help

  13. C. Michael Pilato says:

    Craig, svnsync stores revision properties on the mirror repository which record the source repository URL and UUID, as well as some state information. (This is why you need to provide the source URL only at ‘svnsync init’ time, not during the actual synchronization phases later.) Here’s an example from a mirror I keep on my box:
    $ svn plist -v –revprop -r0 file:///usr/local/svn/subversion | grep svn:sync
    svn:sync-from-uuid : 612f8ebc-c883-4be0-9ee0-a4e9ef946e3a
    svn:sync-last-merged-rev : 29943
    svn:sync-from-url : http://svn.collab.net/repos/svn
    $
    You can modify the svn:sync-from-url property’s value to match the new location of the repository you are mirroring using the “propedit” subcommand:
    $ svn pedit -r0 –revprop svn:sync-from-url MIRROR-REPOS-URL
    Hope that helps!

  14. Craig Menke says:

    Mike,
    We are working on a Windows 2003 server, and when we run this command it seems as though we are connecting to the repository but cannot change the property. Here is a copy of our command we are running:
    svn pedit -r15 –revprop svn:sync-from-url https://10.x.xx.xx/svn/npers
    Once we run this command we are prompted for credentials. We get past all that (logging in it seems), but then a text editor pops up (file name: svn-prop.tmp) and I am not sure if I am supposed to enter the new IP of the Master or what.
    Thanks again for any help!

  15. C. Michael Pilato says:

    Sorry, Craig. I meant to point out that these properties live only on revision 0. So try the command again as:
    svn pedit -r0 –revprop svn:sync-from-url https://10.x.xx.xx/svn/npers
    Your text editor should pop up with a file populated with the current value of that property. Change the value, save the file, and exit the editor.

  16. Craig Menke says:

    Mike,
    Thank you!! It worked fine once we realized that we needed to truly use the path to the MIRROR and NOT the MASTER.

  17. Jay Kumar says:

    Hi mike ,
    The Blog is really helpful .I am able to set up Master-Slave replication with Write-Thru Proxies and able to work with Tort. SVN as per the requirement But when I try to use “SVNAutoversioning On” feature So that we can use the shared Drive and IE for version Control, It is working fine On Master But not On slave.It should automatically redirect the Commits to Master which is not taking Place.Is there a way to do the same So that we can use this feature with SVN.

  18. Barrie Duncan says:

    Hello Mike,
    Thanks for the post, very helpful.
    I have got it all working except for commits to the slave aren’t being proxied through to the master? I can see in the apache log on the master receiving the packets from the slave. But get an error in my SVN client when trying to commit.
    Regarding the apache setup, is mod_proxy the only extra module to be loaded? I tried loading the http_proxy as well, without this the proxy appeared to not do anything (didn’t get anything on the master apache log).
    I’m guessing it is something simple, could you please email me some working config files to help me out.
    Thanks

  19. Fei says:

    Hi Mike, Thanks for the post, it helps a lot.
    But I still have a problem with it. Let me describe my scenario first.
    I’m currently setting up a slave subversion server behind cooperation firewall. The master subversion server is outside my company. And it’s unable for me to setup a svnsync in master’s post-commit hook since the slave server is invisible from the master server. The VPN solution is too expansive. Once I commit to the slave server, it write through the data to master server. But after the commit, the master has the higher revision but the slave still has the original revision. I guess that’s because the slave just to the write through job and doesn’t apply the changed to itself. And I doesn’t get any confirmation from master after the commit. So I tried to set up a post-commit hook on slave. I setup a sync in the post-commit so that each time I commit to slave. It will write through to master and sync with master after the commit as well. But it turns out that the post-commit hook on slave is never activated each time I commit to slave.
    Is it designed to work in this way? When write through is setup, post-commit will not be called during normal commit?
    Thanks!

  20. C. Michael Pilato says:

    @Fei: Yes, it is per the design of the system that the slave’s commit-related hooks don’t trigger in this scenario. (Consider if they did: they’d run twice, once at “commit” time, and once when the data was svnsync’d back into place; also, the first time they ran they’d have to know to contact another repository to fetch info about the commit, but how would they distinguish between a proxied commit and a real one?) Anyway, if you can’t make the master poke the server directly when it needs to tell it to update itself, you might instead look at setting up a polling system on the slave which routinely asks the master if there are any changes. If you are forced to go this route, though, you might want to read my blog post about mirror management (http://blogs.open.collab.net/svn/2008/05/how-often-shoul.html) just so you are aware of the challenges.

  21. Jay Kumar Sharma says:

    Hi Mike,
    when I try to use “SVNAutoversioning On” feature So that we can use the shared Drive and IE for version Control, It is working fine On Master But not On slave.It should automatically redirect the Commits to Master which is not taking Place.Is there a way to do the same So that we can use this feature with SVN.If you can let me know some thing about this??.

  22. Nick says:

    Hi,
    Thanks for providing such useful information about replication. Can anyone provide some in-sight on how the replication of a slave server be remove.
    Thanks in advance
    Nick

  23. Henry says:

    Hi Mike,
    It’s an excellent doco. I used it and my setup went very smooth. Commit works nicely at mirror site.
    When I try svn copy at mirror site (we need create tags at mirror site during build). I got an error tho. It seems “svn copy” try to do it at mirror site itself instead of going thru master site.
    C:tempBlueChip_Mirror>svn copy -m “” http://myhost/My_Mirror/trunk/Proj1 http://myhost/My_Mirror/bra
    nches/Proj1
    svn: Server sent unexpected return value (405 Method Not Allowed) in response to
    COPY request for ‘/My_Mirror/!svn/bc/21/trunk/Proj1’
    I used subversion 1.5.5, apache 2.2.11 on windows xp.
    Many Thanks
    Henry

  24. C. Michael Pilato says:

    @Henry: Do your master/mirror server logs give any more information about the error? Are you going through any proxies or additional Apache configury that would prevent COPY request types (in general) from happening?

  25. Ryan Nagy says:

    Mike,
    I am trying to setup a write-through proxy and I am having an issue with gaining access to the actual repository through a browser. I can authenticate to the parent path and see the “repository collection” page without a problem, however when I try to select the actual repository it errors out on me (ie. “https://xx.x.xx.xx/svn/” works, but “https://xx.x.xx.xx/svn/slave” does not). With the write through proxy is this not What am I missing here?
    I currently have three location blocks:
    which has the ldap and accessfile configurations
    which has the MasterURI
    .
    I have a feeling the issue has something to do with the SVNPath (SVNPath C:svnslave and in the Location Block that houses the ldap it looks at C:svn), but if I change any of the location blocks I get access denied errors.
    If you need more particulars let me know.
    Thanks!
    Ryan

  26. Ryan Nagy says:

    Forgot about the brackets:
    Location /svn/ – which has the ldap and accessfile configurations
    Location /svn/slave – which has the MasterURI
    Location svn/slave-sync

  27. Ryan Nagy says:

    Sorry, in my previous post I had code snippets that were removed.
    Under “I currently have three location blocks it should read as:
    I currently have three location blocks:
    Location /svn/ – which has the ldap and accessfile configurations
    Location /svn/slave – which has the MasterURI
    Location svn/slave-sync
    – Ryan

  28. Andrea Polci says:

    Myke,
    Is it possibile to relocate an existing project from the main repository to the proxy?
    I tried but I get an error saying they are different repositories, I think cause the mirror have a different UUID.
    Is it ok if I set the UUID of the proxy to be the same of the main repository?
    I also tried to set up another proxy under windows XP (master and first proxy are under linux) and got the same error as Henry. The error log shows this warning:
    proxy: No protocol handler was valid for the URL /svn/areas/!svn/act/adeeeea3-2001-0010-bd20-439964a21dd2. If you are using a DSO version of mod_proxy, make sure the proxy submodules are included in the configuration using LoadModule.
    I tried to enable all the proxy submodules I have in my http.conf but it don’t make any difference.
    Dont’ know if it’s important but while I access the mirror throw http, the main repository require https access.
    Thanks for any help,
    Andrea

  29. C. Michael Pilato says:

    @Andrea: By “relocate an existing project”, I’m assuming that you mean ‘svn switch –relocate’. Yes, I would expect you to get the UUID mismatch error in that case. Certainly it is your goal to treat your main repository and your proxy repositories as the same, so it makes sense to have their UUIDs the same. You can do this by using the ‘svnlook uuid’ and ‘svnadmin setuuid’ on your repositories.
    The problems that many folks have been having with copy operations through the proxy is a known bug in some versions of Subversion. It’s hopefully fixed in Subversion 1.6.0, but has proven to be a slippery sucker to catch.
    As for the https/http mismatch, I’m not sure what to expect from that configuration, having not attempted it myself.

  30. Tal Abramson says:

    Has anyone stumbled upon this error message? :
    svn ci -m”test”
    svn: Commit failed (details follow):
    svn: At least one property change failed; repository is unchanged
    svn: Server sent unexpected return value (405 Method Not Allowed) in response to PROPPATCH request for ‘/svn-slave!svn/wbl/c2d89e7a-a667-0410-8024-113d7d95a7f8/10’
    I keep getting it when trying to commit to a slave
    i get it when my main server is the master as well as the slave
    so my guess is that it Apache issues
    Which modules are involved?

  31. C. Michael Pilato says:

    @Tal: This URL looks wrong: ‘/svn-slave!svn/wbl/c2d89e7a-a667-0410-8024-113d7d95a7f8/10’ There should be a slash (/) after ‘/svn-slave’ and before ‘!svn’. httpd.conf configuration problem?

  32. Tal Abramson says:

    I have tested the url several times (all options of slashes …)
    so no , it is not a configuration issue (i use the minimal configuration)

  33. jay says:

    @Tal. I faced this Issues my self on SVN > 1.5.5. After two days I found that there was commits made to this version to fix the bug of Lock propagation not working with write through proxy in file mirror.c and you need to have just a “/” for you configuration here like
    Location /svn/project-proxy-sync/
    DAV svn
    SVNPath /opt/svn/project/
    Order deny,allow
    Deny from all
    Allow from IP-ADDR-OF-MASTER
    not sure if you are using SVN > 1.5.5 but this may help you.

  34. Nick says:

    Hi ,
    I want to replicate the locks from master to slave and vice versa. Please anyone can help me how we can configure the post-lock and post-unlock hook scripts.
    Thanks
    Nick

  35. Nick says:

    Hi ,
    Has anybody configured the post-lock and post-unlock hook scripts for replicating locks from master to slave.
    Here is the configuration which i am using for post-lock hook script.
    #!/bin/bash
    REPOS=”$1″
    USER=”$2″
    /Library/Apache/HTTPD/2.2.11/Subversion/bin/svn lock –force https:///del-sync/delsa3rsngbuild -m “Lock set on master by $USER on path $REPOS”
    But this didn’t worked and failed. ( while taking the lock on file : it gave : Lock succeeded, but post-lock hook failed )Also running the command – svn lock –force https:///del-sync/delsa3rsngbuild gave the following message.svn: OPTIONS of ‘https:///del-sync’: 200 OK (https://)
    Can anybody help me on this.
    Thanks
    Nick

  36. C. Michael Pilato says:

    I seem to recall some fairly frustrating issues with locking in a WebDAV mirror context. I’m having trouble locating the discussion thread in which this topic was covered. Seems like it was just a couple of months ago at most, though.
    In your hook, I don’t see how your are representing the locked path. Looks like you’re always trying to lock the same slave server URL, regardless of the path the user is trying to lock (which is/are provided via stdin, one path per line). That’s doesn’t sound right. At a minimum, I would have expected something like (this is untested code … drop the backticks which I’m using only to preserve initial spaces):
    ————————[ post-lock ]—————————
    #!/usr/bin/env python
    import sys
    import os
    import urllib
    svn_path = ‘/Library/Apache/HTTPD/2.2.11/Subversion/bin/svn’
    repos = sys.argv[1]
    user = sys.argv[2]
    # Lock each path provided to us via stdin on the slave. We have to URI-encode the paths
    # when using them as URL portions.
    while 1:
    ““line = sys.stdin.readline()
    ““if not line:
    ““““break
    ““line = line.rstrip()
    ““cmd = ‘%s lock –force https:///del-sync/delsa3rsngbuild/%s -m “%s locked on master by %s”‘
    “““““% (svn_path, urllib.encode(line), line, user)
    ““os.system(cmd)

  37. Ido S says:

    Hi,
    I configured the proxy redirection, but I am facing a big that prevent adding new files from the slave. This is document here:
    http://subversion.tigris.org/issues/show_bug.cgi?id=3275
    http://groups.google.com/group/tortoisesvn/browse_frm/thread/b1a50e03fd5dbe72/e0856dbafbe5a4e7?lnk=gst&q=proxy#e0856dbafbe5a4e7
    Does anyone know if there is a solution to this bug ?
    Thanks, Ido

  38. C. Michael Pilato says:

    @Ido: The solution to the bug you referenced in documented in the bug report itself, and is reported there (as well as in the Subversion CHANGES file) has having been released in Subversion 1.5.5. Verify that you are running at least Subversion 1.5.5, and if you are still seeing this problem, reopen issue #3275.

  39. Nick says:

    Thanks Michael for your reply on lock replication.
    I have configured the post-lock hook script using perl for the master repository as follows :
    #!/bin/bash
    REPOS=”$1″
    USER=”$2″
    read PATH
    echo “REPOS: $REPOS; PATH: $PATH; USER: $USER” > /tmp/HELLO.txt
    /Library/Apache/HTTPD/2.2.11/Subversion/bin/svn lock –force –username abc –password abc “https:///slave/repositoryName$PATH”
    Problem: When a lock is applied on the master repository and the post-lock script is fired using the tortoise client, the client hangs and causes various apache instances to be started. I guess this process is going in infinite loop.
    Please let me know if you have any clues.
    Thanks
    Nick
    Thanks
    Nick

  40. C. Michael Pilato says:

    @Nick: You appear to be using bash, not Perl, but whatever. Infinite loops are bad, but they should be avoidable: you ought to be able to expose your repository via two different Apache Location blocks on the slave server(s), one that proxies to your master, and one that does not. Use the second one when mirror commits and locks from the master to the slave.

  41. Nick says:

    Hi
    Thanks for your reply . The lock replication worked when i used the slave-sync url :
    Here is the hook script
    #!/bin/bash
    REPOS=”$1″
    USER=”$2″
    read PATH
    Library/Apache/HTTPD/2.2.11/Subversion/bin/svn lock –force –username $USER –password ‘abc’ https://IP of slave/slave-sync/repositoryName/$PATH
    But the problem with the above script is that we have mentioned password for a specific user. In case of multiple users how we can handle this.
    We have used post-lock script without specifying any credentials but it failed with the Apache logs saying that “Anonymous access not allowed”.
    Also in the post-commit host script also i am using the https://IP of slave/slave-sync/repositoryName/ , there i am not specifying the password whereas why it is necessary to provide the password in case of svn lock.
    Is there any other way by which the ‘username’ who has taken the lock be replicated without hard coding the password in post-lock hook script.
    Thanks in Advance,
    Nick

  42. C. Michael Pilato says:

    @Nick I can’t help but wonder if ultimately you’re going to run into bigger hurdles than this. For example, even if you succeed in locking the slave from the master, the lock token associated with that lock will differ from the lock token that the user has in his working copy. Subversion 1.6 offers so help here in that, if you could somehow get the master to tell the slave the lock token it has, the slave’s pre-lock hook script could use the same token.
    I was hoping that maybe the lock comment sent from the master could carry the information the slave needs (username, lock-token), but it doesn’t appear that the lock comment is available to the pre-lock hook script on the slave.
    In summary: version control is hard — let’s go shopping.

  43. Nick says:

    SVN move and rename not working for files and folders in slave repository
    Apache : 2.2.11
    Subversion server : 6.2
    While rename a file it gives the following error
    svn: Commit failed (details follow):
    svn: Server sent unexpected return value (405 Method Not Allowed) in response to COPY request for ‘/slave/qa1/helloiamthe_masteronqa1/!svn/bc/17/branches’
    Similarly while moving the folder gives the following error
    svn: Server sent unexpected return value (405 Method Not Allowed)
    Please let me know if anyone has any clues on this.
    Thanks
    Nick

  44. Nick says:

    SVN move and rename not working for files and folders in slave repository
    Apache : 2.2.11
    Subversion server : 6.2
    While rename a file it gives the following error
    svn: Commit failed (details follow):
    svn: Server sent unexpected return value (405 Method Not Allowed) in response to COPY request for ‘/slave/qa1/helloiamthe_masteronqa1/!svn/bc/17/branches’
    Similarly while moving the folder gives the following error
    svn: Server sent unexpected return value (405 Method Not Allowed)
    As per the apache logs : the error is :
    [error] (2)No such file or directory: Requests for a collection must have a trailing slash on the URI.
    Upon investigating we found a link http://tortoisesvn.net/node/111
    where we have changed the SCM configuration to have a tailing slash in SCM Location.
    DAV svn
    SVNParentPath /Users/Subversion
    SVNAutoversioning on
    AuthType Basic
    Require valid-user
    Options +ExecCGI
    SetHandler perl-script
    PerlHandler ModPerl::PerlRun
    PerlAuthenHandler LDAP::Authenticate
    But this didn’t worked as expected.
    Do we require to provide rewrite option as well in the Location for SCM configuration
    DAV svn
    RewriteEngine on
    RewriteCond %{REQUEST_METHOD} !^GET$
    RewriteCond %{REQUEST_METHOD} !^PROPFIND$
    RewriteCond %{REQUEST_METHOD} !^OPTIONS$
    RewriteCond %{REQUEST_METHOD} !^REPORT$
    Please let me know if anyone has faced this similar issue.
    Thanks in advance,
    Nick

  45. jay says:

    Hi Mike ,
    I am facing the same problem as Nick the only difference is Apache version which is 2.2.8.If we are not able to implement these basic commands then SVN write through proxy is only suitable for backups.
    Please let us know if this Works Or not Or we need to have some workaround .
    As you are working on this ,Only you can provide us the best possible suggestions.
    Thank you
    regards
    Jay

  46. C. Michael Pilato says:

    @Nick, @Jay: I’m sorry that you guys are experiencing issues with locking in your WebDAV proxy setups. I’d like to see those resolved. Unfortunately, I can only kinda imagine a worse interface for discussions than in a blog comment roll. 🙂 Are you able to subscribe to dev@subversion.tigris.org long enough to post a writeup of the problems you are seeing and survive the ensuing discussion around solutions? I’ll happily watch for your post(s) there and contribute to the thread. My hope is that we can get some of the other devs to pay attention, too.

  47. Nick says:

    Thanks for the update Michael . I have send the issue on the dev@subversion.tigris.org with the title :
    Issue | Moving and Renaming files on Mirror/Slave repository. Getting the following error :
    svn: Commit failed (details follow):
    svn: Server sent unexpected return value (405 Method Not Allowed) in response to COPY request for ‘/slave/qa1/helloiamthe_masteronqa1/!svn/bc/17/branches’

  48. Isaac says:

    In response to (405 Method Not Allowed) in response to MKACTIVITY:
    make sure you load proxy, proxy_http
    (e.g. sudo ln -s /etc/apache2/mods-available/proxy.load /etc/apache2/mods-enabled/proxy.load)
    (e.g. sudo ln -s /etc/apache2/mods-available/proxy.conf /etc/apache2/mods-enabled/proxy.conf)
    (e.g. sudo ln -s /etc/apache2/mods-available/proxy_http.load /etc/apache2/mods-enabled/proxy_http.load)
    In response to (405 Method Not Allowed) in response to PROPPATCH
    regardless of what’s been written above, I find that NOT having a trailing slash in my SVNMasterURI fixes this.
    e.g. a setup i used the provides proxied server and Active Directory authentication (for that, enable authnz_ldap.load,ldap.load and vi /etc/ldap/ldap.conf and set REFERRALS off because Exchange is moronic and you need to do that)
    On Master, exposing the repos:
    DAV svn
    # all the repositories that have this server as a master
    # should be /mnt/svn/-mastered
    SVNParentPath /svnroot/mastered
    SVNListParentPath on
    # Authentication block
    AuthBasicProvider ldap
    AuthType Basic
    AuthzLDAPAuthoritative off
    AuthName “MYCOMPANY AD Authentication”
    # e.g. if i worked at oracle, for instance, it would be dotdc1.oracle.com:389/DC=oracle,DC….
    #also, i had my IT guy make me a special domain user “svnldap”.. just to test this, you can use your own user/pass
    AuthLDAPURL “ldap://dotdc1.mycompany.net:389/DC=mycompany,DC=net?sAMAccountName?sub?(objectClass=*)” NONE
    AuthLDAPBindDN “svnldap”
    AuthLDAPBindPassword xxxsvnldappasswordxxx
    Require valid-user
    On Slave, exposing the repos:
    DAV svn
    SVNParentPath /svnroot/synced
    #in this case, the first svn refers to my server name, which is “svn”
    #this could be http://myserver.mycompany.net/svn instead
    SVNMasterURI http://svn/svn
    AuthBasicProvider ldap
    AuthType Basic
    AuthzLDAPAuthoritative off
    AuthName “MYCOMPANY AD Authentication”
    AuthLDAPURL “ldap://dotdc1.mycompany.net:389/DC=mycompany,DC=net?sAMAccountName?sub?(objectClass=*)” NONE
    AuthLDAPBindDN “svnldap”
    AuthLDAPBindPassword xxxsvnldappasswordxxx
    Require valid-user

Leave a Reply

Your email address will not be published. Required fields are marked *

*