How do you fix an SVN 409 Conflict Error

I am on very thin ice here (409 being not very specific) but I am able to formulate two questions:

1. Are there any pre- or post-commit hooks in place?
2. Is "Autoversioning" enabled?

If there are any hooks, are you sure they don't contain any errors? Could you disable them for a test? If Autoversioning is not enabled, could you try to enable it for a test? This should work along the lines of

<Location /repos>  DAV svn  SVNPath /var/svn/repository  SVNAutoversioning on</Location>

when using mod_dav_svn (see Link to Autoversioning above).

Maybe this would help to shed some light on your issue and we (and/or Google :)) could take it from there.

Btw: The logs you posted are not from the same commit, right? The time difference would be huge?!?

Edit:Apologies if you found that long ago but I will give it a shot: Could not MERGE resource on COMMIT (Apache 2.0.55) is something that Google found for me :)

The OP there writes that "Apache dictates the version of APR to use". This means that you have to reference the correct APR-version when compiling SVN. I installed SVN (v1.6.9) through MacPorts on my system (OS X 10.6). I do not use WebDAV or Apache locally but I have APR 1.3.12_1 installed (just for reference). The OP suggests to use --with-apxs=/path/to/bin/apxs when compiling SVN although I am not sure if this applies to your situation (I started to guess long ago, you might notice :)).

Any chance you could check the APR-version Apache expects vs. the one used to build SVN (e.g. you could use sudo port installed apr to see what APR-versions live on your system if you are using MacPorts)?

Just for reference an excerpt from Building Apache the Way You Want It:

apxs is a stand-alone utility for compiling modules dynamically without the need to use the configure script or have the Apache source code available. It does need Apache’s header files, though, which are copied to the location defined by --includedir when Apache is installed. However, it’s important to use an apxs that was built with the same configuration options as Apache; otherwise, it’ll make erroneous assumptions about where Apache’s various installation locations are.

I have two ideas of where the problem may be hiding, that are of course wild guesses, so be warned.

On one hand it can just be a file permissions issue. I know, it sounds silly, but perhaps there is some configuration file, or a hook as scherand suggested, or even some folder within the repository structure that was left unreadable either by the update to 10.6 or when building the new svn version, so I'd double check that.

The second idea is to check the compatibility of the svn working copy-client-server-repository versions. The guys from subversion swear that both 1.5 and 1.6 do not break compatibility at the repository level with 1.4 (albeit they do that on working copies). But it would not hurt to check that the format of the whole stack is consistent. And while you're at it, make sure that the apache libraries that you built are compatible with the apache 2.2.11 that comes with 10.6 (again, they should, but you never know)

And finally, good luck.

First establish a baseline. On a stock install of Snow Leopard (10.6.3) here's exactly what I did.

Created "/etc/apache2/other/svn.conf" with content:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so<Location /svn>    DAV svn    SVNParentPath /usr/local/svn    AuthType Basic    AuthName "Subversion repository"    AuthUserFile /usr/local/svn/htpasswd    Require valid-user</Location>

Created subversion folder and repository "test":

sudo mkdir /usr/local/svnsudo svnadmin create /usr/local/svn/testsudo chown -R _www:_www /usr/local/svnsudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass

From normal user, home directory:

macmini:~ jclark$ mkdir Checkout && cd Checkoutmacmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/testAuthentication realm: <http://localhost:80> Subversion repositoryPassword for 'testuser':Checked out revision 0.macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txtA         test.txtAdding         test.txtTransmitting file data .Commited revision 1.macmini:test jclark$

Now, if all of that worked as it should, then you have a working stock 1.6.5 subversion repository served by apache. If it didn't, then you are most likely either mixing apple supplied svn binaries/libs with your own (macports, etc) or there are permissions problems. Make sure you are using the apple provided binaries. Apple does modify the source slightly and I have run into compatibility issues when mixing 'ports' with 'stock' in the past. As for permissions, apache runs as user _www, group _www. Make sure all the files and directories are owned as such, and don't forget to update them whenever you use svnadmin or something else to directly manipulate the svn repository.

Since that is working, move your 'svn2' repository back into /usr/local/svn (if you haven't already), do a clean checkout somewhere, and try a test commit.

If you are still running into problems, try to upgrade the repository.

sudo svnadmin upgrade /usr/local/svn/svn2sudo chown -R _www:_www /usr/local/svn/svn2

Repeat the checkout / commit test.

As a last resort, dump and load the repository again.

sudo svnadmin dump /usr/local/svn/svn2 > /tmp/svn2.dumpsudo svnadmin create /usr/local/svn/svn3sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dumpsudo chown -R _www:_www /usr/local/svn/svn3

Repeat the checkout / commit test, this time with /svn/svn3.

Enjoy your fixed repository... hopefully :)

update

There may be a bug in the subversion command line client. After doing:

mkdir \!vcc && touch \!vcc/defaultsvn add \!vcc && svn commit -m 'test'svn log

Notice the output of svn log (at least for me) is nothing. Svn log from tortoise is fine, which indicates the server (as setup above) is working correctly.

Another thing to try is accessing the repository via 'file' instead of 'http'. Copy the entire repository to your home directory or somewhere your user is the owner, then check it out (ie. svn checkout /Users/Shared/svn/svn2) and try to commit.