résolution des conflits dans Subversion

Question

Bonjour,

J'ai un problème avec le « Arbre conflit » où la situation est la suivante: - Le site a mis en garde que pour résoudre ce problème devrait passer au serveur 1.6 et 1.6 client, mais je a fait les mises à niveau, mais il dit seulement, mais ne corrige pas correctement.

Problème:

• utilisateur A reçu un projeto.c et valider le fichier après la validation version était 30.

• utilisateur B fait une caisse avant COMMIT et était dans la version 29 du fichier Projeto. c où il a déplacé le fichier dans un autre dossier appelé "main" et effectué la validation.

• Les résultats de l'engagement utilisateur B:

Lors de l'exécution commit a été conflit indétectable et a averti que la version est obsolète, alors il a fait une mise à jour et a été montré que le conflit était dans la soi-disant "trois conflits" après qu'il a demandé de résoudre et a tenu à s'engager à la version 32 et non 31. a été détecté que la version 31 il a supprimé le bon fichier le fichier utilisateur et ajouté l'ancien utilisateur B. le 32 il montre seulement le commit et effacez à nouveau.

Résultat final: Le fichier projeto.c était dans la « principale » avec la version 29.

Comment résoudre correctement cette situation? Comment effectuer une mise à jour avant lorsque l'utilisateur effectue une validation automatiquement?

thx

réponse Attendent

Answer 1

Si je comprends bien:

user1> svn co file:///var/svn/repo 
Checked out revision 29. 
.... 
user2> svn co file:///var/svn/repo 
Checked out revision 29. 
.... 
user1> svn mv foo ./dir/ 
A   dir/foo 
D   foo 
user1> echo 'some more work' >> dir/foo 
... 
user2> svn rm foo 
D   foo 
user2> svn ci -m'we don not need foo anymore' 
Deleting  foo 
Committed revision 30. 
... 
user1> svn ci -m'refactoring of foo has worked' 
Adding   dir/foo 
Deleting  foo 
svn: Commit failed (details follow): 
svn: '/foo' is out of date 
user1> svn up 
    C foo 
At revision 30. 
Summary of conflicts: 
    Tree conflicts: 1 
user1> svn stat 
!  C foo 
     > local delete, incoming delete upon update 
A + dir/foo 

Maintenant, user1 & utilisateur2 aller boire une tasse de café avec l'autre, et de décider ce qui en fait à faire . S'ils décident foo devrait rester, ce qui aurait dû se produire (mais je ne suis pas vraiment ce qui a mal tourné ici):

user1> svn resolve --accept=working foo 
Resolved conflicted state of 'foo' 
user1> svn stat 
A + dir/foo 
user1> svn ci -m'Shiny & glorious reintroduction of foo, all brand new, but with a history' 
Adding   dir/foo 
Transmitting file data . 
Committed revision 31. 
.... 
user2> svn up 
A dir/foo 
Updated to revision 5. 
user2> svn log dir/foo  
user2> tail --lines=1 dir/foo 
some more work 

donc tout devrait être OK. La question est: qu'est-ce qui a mal tourné/n'a pas fonctionné dans le scénario de la question? Je soupçonne que quelqu'un a imaginé une fusion malheureuse.

Quant à la deuxième partie:

« Comment effectuer une mise à jour avant lorsque l'utilisateur effectue une validation automatiquement? »

Ne faites rien automatiquement, il devrait être aux développeurs sur le projet de mettre à jour régulièrement leur propre caisse. L'automatiser ne ferait qu'empirer les choses. Ils devraient être en mesure de gérer ces types de conflits & les résoudre selon les besoins.