1. 技术文章
  2. How do you fix an SVN 409 Conflict Error

How do you fix an SVN 409 Conflict Error

由 元气小坏坏 提交于 2019-11-30 07:08:56

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

Have you tried Versions the SVN client for OSX? Its not a solution to your problem really but maybe an alternative. Me and my team had some issues getting SVN and OSX to talk to each other properly so went looking for alternative clients and Versions worked great for us.

Solon
chown -R apache:apache svn

chmod -R 770 svn

This solved the conflict to me: I made a backup of my local files, then pulled everything from the server. Then, when I inserted and pushed my backup files, the 409 conflict error did not appear again.

Regards, Kevin

标签
svn
apache
macos
subversive
osx-snow-leopard
易学教程内所有资源均来自网络或用户发布的内容，如有违反法律规定的内容欢迎反馈！
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!