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!

Solution 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.

Solution 2

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/svn
sudo svnadmin create /usr/local/svn/test
sudo chown -R _www:_www /usr/local/svn
sudo htpasswd -cb /usr/local/svn/htpasswd testuser testpass

From normal user, home directory:

macmini:~ jclark$ mkdir Checkout && cd Checkout
macmini:Checkout jclark$ svn --username testuser checkout http://localhost/svn/test
Authentication realm: <http://localhost:80> Subversion repository
Password for 'testuser':
Checked out revision 0.
macmini:Checkout jclark$ cd test && touch test.txt && svn add test.txt && svn commit -m 'test' test.txt
A         test.txt
Adding         test.txt
Transmitting 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/svn2
sudo 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.dump
sudo svnadmin create /usr/local/svn/svn3
sudo svnadmin load /usr/local/svn/svn3 < /tmp/svn2.dump
sudo 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/default
svn 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.

Solution 3

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.

Comments

[NerdStarGamer]

I did try that a while ago. I wasn't too crazy about it. The trouble here is that I had everything working perfectly on 10.5 with SVN 1.4. Now, nothing seems to be working.

[Rob Segal]

I understand. Sorry I can't be of more help.

[NerdStarGamer]

There are not hooks in place (unless there's something on by default that I'm unaware of). And no, it looks like those two logs are not from the same to commit. Adding the autoversioning bit to my svn.conf didn't seem to have any effect on the issue. Thanks for your help. I'm at my wits end on this one.

[NerdStarGamer]

Niether of those are silly suggestions. I have used chown -R www:www /usr/svn/ on all of my repositories. I also even tried opening the permissions to 777 just to see if it would have any effect. It didn't. Is there some other permissions setting that I'm missing here? At first I assumed the problem was with my old repositories, so I tried updating them, which didn't seem to do anything. I've also at this point created several brand new repos for testing. Same error with those too.

[NerdStarGamer]

I can't see any problems with svn 1.6.9 and the default apache 2.2.11. Perhaps I'm missing something? When I built my copy of subversion, I didn't using any options while configuring it. Could this be part of the problem?

[scherand]

I added another thought that I glued together from various Google-results. It makes some kind of sense to me but admittedly it is very vague.

[NerdStarGamer]

Thanks for suggesting this. I was setting up a new computer with snow leopard to start testing to find out where I went wrong. But now I have figured out the solution and thankfully don't have to go down this route.

[NerdStarGamer]

Nice. I finally got it working. It was those aprs as you suggested.