How do you fix an SVN 409 Conflict Error

Question

I used to use SVN 1.4 on OS X Leopard and everything was fine. A couple of weeks ago I installed a fresh copy of OS X 10.6. The version of SVN that comes with Snow Leopard is 1.6.5. I went ahead and built my own copy with 1.6.6. I'm using the built in apache server and just hosting repositories locally.

Everything appeared to work fine until I actually tried to commit something. Everytime I try to commit a change, I get the following message:

Transmitting file data .svn: Commit failed (details follow):
svn: MERGE of '/svn/svn2': 409 Conflict (http://localhost)

This happens with my old repositories, so I created a couple of new ones. Same deal. I also tried using the 1.6.5 version that comes with the system...same. Finally, I tried upgrading to the latest stable SVN (1.6.9) and still got the same problem.

The Apache error logs the following for each failed commit:

[Mon Mar 29 19:53:10 2010] [error] [client ::1] Could not MERGE resource "/svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1" into "/svn/svn2".  [409, #0]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] An error occurred while committing the transaction.  [409, #2]
[Mon Mar 29 19:53:10 2010] [error] [client ::1] Can't open directory '/usr/local/svn/svn2/db/transactions/5-6.txn/\xeb\xa9\x0f\x1f': No such file or directory  [409, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Could not DELETE /svn/svn2/!svn/act/d399326f-c20f-424f-bb68-3bb40503b5b1.  [500, #0]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] could not open transaction.  [500, #2]
[Mon Mar 29 19:53:11 2010] [error] [client ::1] Can't open file '/usr/local/svn/svn2/db/transactions/5-6.txn/props': No such file or directory  [500, #2]

And from the access log:

::1 - - [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 401 401
::1 - user [30/Mar/2010:13:02:20 -0400] "OPTIONS /svn/svn2 HTTP/1.1" 200 188
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2 HTTP/1.1" 207 647
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/vcc/default HTTP/1.1" 207 398
::1 - user [30/Mar/2010:13:02:20 -0400] "PROPFIND /svn/svn2/!svn/bln/6 HTTP/1.1" 207 449
::1 - user [30/Mar/2010:13:02:20 -0400] "REPORT /svn/svn2/!svn/vcc/default HTTP/1.1" 200 1172

Curiously, the commit does actually commit the changes, but the working copy doesn't see that and everything gets screwy.

I've tried to Google every variation I can think of for this problem, but the search results are pretty much useless. I'm not using TortoiseSVN or anything special and commits fail on a new repository, so I know it's not a problem with my old repos.

Any help would be greatly appreciated.

Update
I've tried adding autoversioning to my svn.conf file. Here's what my files says:

LoadModule dav_svn_module /usr/libexec/apache2/mod_dav_svn.so
<Location /svn>
  DAV svn
  SVNParentPath /usr/local/svn
  SVNAutoversioning on

  # how to authenticate a user
  AuthType Basic
  AuthName "Subversion repository"
  AuthUserFile /usr/local/etc/svn-auth-file

  # only authenticated users may access the repository
  Require valid-user
</Location>    

Update (Solution)

I just wanted to update this with the actual solution in case anyone else is having the same problem with the completely unhelpful error messages. The problem was with the apr and apr-util parts (as scherand suggested). I was building a copy of both using the subversion dependencies package. OS X 10.6 also has it's own version. Both versions were 1.3.8. Apparently though, I needed to use the versions that the default apache install was using.

So, I deleted the apr and apr-util folders from my subversion build, to make sure that I wasn't building my own copy of these again. I built svn from source again, this time using the following configuration:

./configure --with-apr=/usr/bin/ --with-apr-util=/usr/bin/ --with-ssl

After building again, I restarted apache, and created a new svn repo. I was able to check it out, make changes, and commit without any issues. I then tried my old repos and those worked as well.

Thanks everyone for the help!

Answer 1

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.