Comment réparer une erreur de conflit SVN 409

Question

Je l'habitude d'utiliser SVN 1.4 sur OS X Leopard et tout allait bien. Il y a quelques semaines j'ai installé une nouvelle copie de Mac OS X 10.6. La version de SVN qui est livré avec Snow Leopard est 1.6.5. Je suis allé de l'avant et construit ma propre copie avec 1.6.6. J'utilise le construit dans le serveur apache et juste hébergement dépôts sur place.

Tout semblait bien fonctionner jusqu'à ce que j'ai essayé de commettre quelque chose. Chaque fois que je tente de commettre un changement, je reçois le message suivant:

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

Ce qui se passe avec mes anciens dépôts, donc je crée deux nouveaux. beaucoup même. J'ai aussi essayé d'utiliser la version 1.6.5 qui est livré avec le système ... même. Enfin, j'ai essayé mise à niveau vers la dernière SVN stable (1.6.9) et encore eu le même problème.

L'erreur Apache enregistre les éléments suivants pour chaque échec 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]

Et à partir du journal d'accès:

::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

Curieusement, la commettras ne commet en fait les changements, mais la copie de travail ne voit pas et tout se çela.

J'ai essayé de Google toutes les variantes que je peux penser à ce problème, mais les résultats de la recherche sont à peu près inutile. Je ne suis pas en utilisant TortoiseSVN ou quelque chose de spécial et archivages échouer sur un nouveau dépôt, donc je sais que ce n'est pas un problème avec mes vieilles prises en pension.

Toute aide serait grandement appréciée.

Mise à jour Je l'ai essayé d'ajouter à mon dossier Autoversioning de svn.conf. Voici ce que mes fichiers dit:

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>    

Mise à jour (Solution)

Je voulais juste mettre à jour ce avec la solution réelle au cas où quelqu'un d'autre est d'avoir le même problème avec les messages d'erreur complètement inutiles. Le problème était avec les parties et may apr-util (comme suggéré scherand). Je construisais une copie à la fois en utilisant le paquet de dépendances de subversion. OS X 10.6 a également sa propre version. Les deux versions ont été 1.3.8. Apparemment, cependant, je avais besoin d'utiliser les versions qui installent le apache par défaut a été à l'aide.

Alors, je supprimé le dossier APR et de apr-util ma construction de la subversion, pour vous assurer que je ne construisait pas ma propre copie de ces nouveau. Je CONSTRUIT svn à nouveau de la source, cette fois en utilisant la configuration suivante:

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

Après avoir construit à nouveau, je redémarré apache, et a créé un nouveau repo svn. J'ai pu le vérifier, faire des changements, et engager sans aucun problème. J'ai ensuite essayé mes vieux repo et ceux travaillé ainsi.

Merci à tous pour l'aide!

Answer 1

Je suis sur la glace très mince ici (409 étant pas très précis) mais je suis en mesure de formuler deux questions:

1. Y at-il des crochets avant ou après commettras en place?
2. est " Autoversioning" activé?

S'il y a des crochets, vous êtes sûr qu'ils ne contiennent pas d'erreurs? Pourriez-vous les désactiver pour un test? Si Autoversioning n'est pas activé, vous pouvez essayer de lui permettre un test? Cela devrait fonctionner le long des lignes de

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

lors de l'utilisation mod_dav_svn (voir le lien vers Autoversioning ci-dessus).

Peut-être que cela aiderait à faire la lumière sur votre question et nous (et / ou Google :)) pourrait prendre à partir de là.

BTW: Les journaux ne sont pas où vous avez posté le même engagement, non? La différence de temps serait énorme!?

Edit: Toutes mes excuses si vous avez trouvé qu'il ya longtemps, mais je vais donner un coup de feu: pourrait ressources ne fusionnera pas sur COMMIT (Apache 2.0.55) est quelque chose que Google a trouvé pour moi:)

L'OP il écrit que "Apache dicte la version de avril à utiliser". Cela signifie que vous devez faire référence à l'APR version correcte lors de la compilation SVN. J'ai installé SVN (v1.6.9) par MacPorts sur mon système (OS X 10.6). Je ne pas utiliser WebDAV ou Apache localement, mais je avril 1.3.12_1 installé (juste pour la référence). L'OP suggère d'utiliser --with-apxs=/path/to/bin/apxs lors de la compilation SVN bien que je ne sais pas si cela s'applique à votre situation (j'ai commencé à deviner il y a longtemps, vous remarquerez peut-être:).)

Une chance que vous pouvez vérifier l'Apache APR-Version attend par rapport à celui utilisé pour construire SVN (par exemple, vous pouvez utiliser sudo port installed apr pour voir ce que l'APR-versions en direct sur votre système si vous utilisez MacPorts)?

Juste pour référence un extrait de Apache Building the Way You Want It :

  

apxs est un utilitaire autonome pour   compiler dynamiquement des modules sans   la nécessité d'utiliser le script configure   ou avoir le code source Apache   disponible. Il n'a pas besoin d'Apache   fichiers d'en-tête, cependant, qui sont copiés   à l'emplacement défini par   --includedir lorsque Apache est installé. Toutefois, il est important d'utiliser un apxs   qui a été construit avec le même   options de configuration Apache ;   sinon, ça va faire erreur   hypothèses sur l'endroit où Apache   divers endroits d'installation sont.

Answer 2

J'ai deux idées de l'endroit où le problème peut se cacher, qui sont des vagues suppositions de cours, alors soyez averti.

D'une part, il peut être juste un problème d'autorisations de fichier. Je sais, cela semble stupide, mais peut-être il y a un certain fichier de configuration, ou un crochet comme scherand suggéré, ou même quelque dossier dans la structure du référentiel qui a été laissé illisible soit par la mise à jour 10.6 ou lors de la construction de la nouvelle version svn, donc je « d Double vérifier.

La seconde idée est de vérifier la compatibilité des versions de travail svn-serveur référentiel copie-client. Les gars de la subversion jurent que les deux 1.5 et 1.6 ne cassent pas la compatibilité au niveau du référentiel avec 1,4 (mais ils le font que sur les copies de travail ). Mais il ne serait pas mal de vérifier que le format de l'ensemble de la pile est cohérente. Et pendant que vous y êtes, assurez-vous que les bibliothèques apache que vous CONSTRUIT sont compatibles avec l'apache 2.2.11 qui vient avec 10.6 (encore une fois, ils le devraient, mais vous ne savez jamais)

Et enfin, bonne chance.

Answer 3

Tout d'abord établir une base de référence. Sur un stock de l'installation Snow Leopard (10.6.3) est là exactement ce que je faisais.

A créé "/etc/apache2/other/svn.conf" avec le contenu:

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>

dossier subversion créé et référentiel "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

De l'utilisateur normal répertoire:

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$

Maintenant, si tout cela a fonctionné comme prévu, alors vous avez un stock de travail 1.6.5 dépôt subversion servi par apache. Si elle n'a pas, alors vous êtes très probablement soit le mélange binaires / libs avec vos propres svn (fourni pomme macports, etc) ou il y a des problèmes d'autorisations. Faire vous vous utilisez les binaires fournis aux pommes. Apple ne modifie légèrement la source et je l'ai rencontrer des problèmes de compatibilité lors du mélange « ports » avec « stock » dans le passé. En ce qui concerne les autorisations, apache fonctionne comme _www utilisateur, groupe _www. Assurez-vous que tous les fichiers et répertoires sont la propriété en tant que tels, et ne pas oublier de les mettre à jour chaque fois que vous utilisez svnadmin ou quelque chose d'autre pour manipuler directement le dépôt svn.

Depuis travaille, déplacez votre « svn2 » dépôt de nouveau dans / usr / local / svn (si vous avez pas déjà), faire une caisse propre quelque part et essayer un test commit.

Si vous êtes toujours en cours d'exécution dans des problèmes, essayez de mettre à niveau le référentiel.

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

Répéter la caisse / commit test.

En dernier recours, et charger le vidage à nouveau référentiel.

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

Répéter la caisse / commit test, cette fois avec / svn / svn3.

Profitez de votre référentiel fixe ... espérons-le:)

mise à jour

Il peut y avoir un bug dans la ligne de commande subversion client. Après avoir fait:

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

Notez la sortie du journal svn (au moins pour moi) est rien. Svn log de tortue est très bien, ce qui indique que le serveur (comme la configuration ci-dessus) fonctionne correctement.

Une autre chose à faire est d'accéder au référentiel via « fichier » au lieu de « http ». Copiez l'intégralité du dépôt de votre répertoire personnel ou quelque part votre utilisateur est le propriétaire, puis le vérifier (ie. Svn checkout / Users / Shared / svn / svn2) et essayer de commettre.

Answer 4

Avez-vous essayé Versions le client SVN pour OSX? Son pas une solution à votre problème vraiment, mais peut-être une alternative. Moi et mon équipe a eu quelques problèmes pour trouver SVN et Mac OS X pour se parler correctement alors je suis allé à la recherche de clients et d'autres versions était parfait pour nous.

Answer 5

chown -R apache:apache svn

chmod -R 770 svn

Answer 6

résolu le conflit à moi: je fait une sauvegarde de mes fichiers locaux, puis tiré tout à partir du serveur. Puis, quand je poussais mes inséré et les fichiers de sauvegarde, l'erreur 409 de conflit ne semble pas encore.

Cordialement, Kevin