web-dev-qa-db-fra.com

Résoudre un conflit de fusion lorsque je fais une mise à jour svn

J'essaie d'apprendre les bases du contrôle de version par Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf

Je suis à la page 22 maintenant. Je vais vous décrire le scénario. Deux utilisateurs sur le même ordinateur, harry et sally, travaillent sur un fichier appelé lottery.c qui est stocké dans un dépôt appelé lottery.

1 - Harry valide le premier code/initial. 2 - Sally le change et s'engage. 3 - Pendant que 2 se produit, Harry a apporté des changements, mais n'a pas commis. 4 - Harry s'engage et obtient une erreur.

Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date

5 - Pour résoudre ce problème, harry mettra à jour sa copie locale en utilisant svn update.

C'est là que j'ai un problème! L'auteur dit que la sortie est:

lottery harry$ svn update
G lottery.c
Updated to revision 2.

Mais ma sortie est:

lottery harry$ svn update
Updating '.':
C    lottery.c
Updated to revision 2.
Conflict discovered in file 'lottery.c'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
        (mc) my side of conflict, (tc) their side of conflict,
        (s) show all options:

Je suis nouveau et je ne sais pas comment répondre à ce message. Mon livre est-il faux? Aidez-moi, s'il vous plaît. Merci.

svn
23
Steam

Lorsque plusieurs personnes modifient le même fichier à la fois, il est très possible que les deux modifient les mêmes lignes. C'est ce qui vous est arrivé. Sally change les mêmes lignes qu'Harry changeait. Quand Harry a fait svn update, Subversion l'a détecté et vous demande quoi faire.

Un mot d'avertissement: Parfois, Subversion ne recherche que des différences dans une ligne entre votre version et leur version, et non des différences significatives. Par exemple, si l'indentation d'une ligne a été modifiée, ou l'espacement était différent, ou si vous avez modifié les fins de ligne, Subversion le déclarera comme un conflit même s'il ne l'est probablement pas. C'est peut-être pourquoi le livre n'a pas trouvé ce problème, mais vous l'avez fait. Cela ne signifie pas que vous avez fait quelque chose de mal.

Que faire? Subversion vous donne plusieurs choix.

  • reporter  p: C'est ce que je fais habituellement avec ce type de situation. Subversion incorporera dans le fichier marqueurs diff qui ressemblent à ceci dans le fichier:

<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx

Cela vous montre les changements dans la révision rxxx (à quoi ressemblait Sally) par rapport aux changements que vous avez (changements de Harry). Habituellement, les changements sont suffisamment mineurs pour qu'il soit assez facile de savoir quoi faire.

  • show diff  df: Cela vous montrera les différences entre vos changements (Harry's) et ce qui est dans l'autre révision (Sally's). Il vous montre essentiellement les marqueurs de différence.
  • modifier  e: Vous pouvez modifier le conflit de fusion au fur et à mesure de la fusion au lieu d'attendre plus tard.
  • fusionner  m: Je ne sais pas trop ce que cela fait. Vous faites la fusion en ce moment, donc cela n'a pas trop de sens.
  • leur côté du conflit  tc: Acceptez ce que Sally a fait pour résoudre le conflit. Vous devez probablement refaire vos modifications, mais au moins vous envisagez les modifications de Sally.
  • mon côté du conflit  mc: Le scénario le plus dangereux car vous ignorez complètement les changements de Sally. Sally a fait un correctif, et vous pouvez éventuellement le corriger. Lorsque la version sortira et que le correctif de Sally n'y figurera pas, vous serez blâmé d'avoir supprimé la modification. Alors, pourquoi fais-tu ça? Parce que vous avez déjà examiné les changements et réalisé que le conflit n'était pas vraiment un conflit. C'était un changement d'indentation ou quelque chose de similaire. Ou vous avez appelé une variable increment et Sally l'a appelée counter.

Comme je l'ai dit, je fais généralement un report, laisse ma mise à jour se terminer, puis gère les problèmes.

Une fois le problème résolu, vous effectuez une svn resolved sur ce fichier pour informer Subversion que vous avez résolu le conflit.

Il existe d'autres choix - par exemple, vous pouvez lancer un outil de diff/fusion tiers pour gérer le conflit.

Pour plus d'informations, consultez le manuel en ligne de Subversion sur résolution des conflits de fusion .

40
David W.

Si vous sélectionnez l'option s, elle vous montrera:

(e)  edit             - change merged file in an editor
(df) diff-full        - show all changes made to merged file
(r)  resolved         - accept merged version of file

(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict    - accept my version for all conflicts (same)
(tc) theirs-conflict  - accept their version for all conflicts (same)

(mf) mine-full        - accept my version of entire file (even non-conflicts)
(tf) theirs-full      - accept their version of entire file (same)

(p)  postpone         - mark the conflict to be resolved later
(l)  launch           - launch external tool to resolve conflict
(s)  show all         - show this list

Utilisez dc pour voir les confidents puis vous pouvez décider de la meilleure option à utiliser

6
99 Problems - Syntax ain't one

Le "G" indique que le fichier a été modifié par quelqu'un d'autre, mais les modifications effectuées par cette personne se trouvaient dans une autre partie du fichier, donc SVN pourrait le fusionner pour vous sans demander d'aide.

Le "C" indique que non seulement le fichier a été modifié par quelqu'un d'autre, mais que ses modifications ont été apportées aux mêmes lignes que vous avez également modifiées, donc SVN ne sait pas quoi faire. Maintenant, c'est VOTRE travail de faire la fusion.

Vous n'avez probablement rien fait de mal, et le livre n'a pas tort, ils ont juste laissé de côté les détails sur les changements spécifiques, apparemment.

1
Ben