résoudre les conflits binaires svn

Question

J'utilise svn pour un projet sur lequel je travaille avec quelques autres développeurs. Svn fonctionne très bien pour le contrôle de code source, mais nous avons tous des problèmes lorsque nous commettons les dll.

Quand je résous le conflit (qui supprime mes dll car le programme diff ne peut pas gérer les fichiers binaires), je dois ensuite le reconstruire pour le valider. Comment comptez-vous résoudre ce genre de conflit?

Modifier:

Les dll sont dans un dossier svn séparé car le projet est un mod de jeu et les non-programmeurs ont besoin d'accéder aux dernières versions.

Answer 1

Comme mentionné dans d'autres réponses ici: vous ne devriez pas mettre à jour vos dll générées. Mais si vous avez vraiment pour les mettre à la version, vous pouvez résoudre un conflit sans utiliser d'outil diff permettant de supprimer vos fichiers dll:

Pour chaque fichier en conflit, Subversion place trois fichiers non versionnés supplémentaires dans votre copie de travail:

nomfichier.mine

Il s'agit de votre fichier tel qu'il existait dans votre copie de travail avant la mise à jour de votre copie de travail, c'est-à-dire sans marqueur de conflit. Ce fichier contient uniquement vos dernières modifications. (Si Subversion considère que le fichier ne peut pas être fusionné, le fichier .mine n'est pas créé, car il serait identique au fichier de travail.)

nom de fichier.rOLDREV

Il s’agit du fichier qui était la révision BASE avant la mise à jour de votre copie de travail. C’est-à-dire le fichier que vous avez extrait avant d’effectuer vos dernières modifications.

nomfichier.rNEWREV

Il s’agit du fichier que votre client Subversion vient de recevoir du serveur lorsque vous avez mis à jour votre copie de travail. Ce fichier correspond à la révision HEAD du référentiel.

Ici, OLDREV est le numéro de révision du fichier dans votre répertoire .svn, et NEWREV est le numéro de révision de HEAD du référentiel.

Maintenant, pour résoudre un tel conflit, supprimez les fichiers supplémentaires que vous ne voulez pas:

• si vous souhaitez conserver votre propre dll, supprimez les fichiers nomfichier.rOLDREV, nomfichier.rNEWREV
• si vous souhaitez conserver la dll du référentiel, supprimez les fichiers filename.rOLDREV et filename.mine, puis copiez filename.rNEWREV dans le nom de fichier
.

après cela, exécutez

svn resolved filename

pour indiquer à Subversion que vous avez résolu le conflit vous-même.

Answer 2

S'il s'agit d'une DLL que vous construisez (plutôt que d'une source externe pour laquelle vous n'avez pas de source), alors la source doit être dans le contrôle de source, pas dans le binaire.

Si vous ne souhaitez pas l'inclure dans ce référentiel particulier, vous pouvez l'inclure en tant que svn: external.

Answer 3

En règle générale, vous ne stockez pas du tout vos propres DLL compilées dans le contrôle de source. Avez-vous une raison spécifique pour laquelle vous devez faire cela?

J'ai configuré mes environnements de développement de sorte que tout le monde puisse construire n'importe lequel des composants de mon projet, indépendamment de tout autre utilisateur. De cette manière, la seule chose qui se trouve dans mon système de contrôle de source est mon code source . Cela présente de nombreux avantages:

• Cela évite les conflits de fichiers binaires lorsqu’on essaie d’archiver des DLL ou des EXE.
• Le volume de données suivies par votre système de contrôle de source est beaucoup plus petit, ce qui le rend plus rapide
• Lorsque les développeurs construisent toujours leurs propres DLL, ils peuvent être raisonnablement certains que le code source dont ils disposent correspond au fichier compilé. Si vous utilisez quelque chose que quelqu'un d'autre a construit, vous ne pouvez jamais en être sûr.

Comme indiqué dans les commentaires, il peut être parfaitement raisonnable de stocker des DLL tierces dans votre système de contrôle de code source, en particulier si vous ne possédez pas le code source. J'ai également travaillé sur des projets dans lesquels nous avons stocké des fichiers de distribution ( .tar.gz , etc.) pour diverses bibliothèques open source dans le contrôle de code source, puis nous avions tout un système de Makefile . qui ont construit ces bibliothèques dans le cadre d’une cible de construction tout.

Answer 4

Pour les fichiers binaires, la plupart du temps, vous souhaitez accepter l'une ou l'autre version. Par exemple, si le fichier en question est un outil exécutable, alors une version peut être plus récente que l’autre, et il peut s’agir de celle que vous souhaitez utiliser.

Pour accepter la version de la branche à partir de laquelle vous effectuez la fusion, utilisez:

svn resolve --accept=theirs-full path/to/filename

Pour accepter la version précédemment présente dans la branche actuelle, utilisez:

svn resolve --accept=mine-full path/to/filename

Parfois, SVN refusera d'utiliser leur code complet avec l'avertissement suivant:

svn: warning: W195024: Option de résolution de conflit non applicable donnée pour un chemin d'accès en conflit

parce que SVN est une merde quand il s’agit de fusionner. Dans ce cas, vous devez copier les fichiers manuellement, comme indiqué dans la réponse acceptée https://stackoverflow.com/a/410767/2279059, plutôt que d'utiliser des options de ligne de commande destinées à ce que vous essayez de faire. Si vous savez que les deux fichiers sont identiques (mais que SVN les marque toujours comme étant en conflit pour des raisons déjà indiquées), vous pouvez également utiliser

.

svn resolve --accept=working path/to/filename

Bien que, dans le cas de fichiers identiques, soit en réalité identique à toutes les autres commandes, SVN ne refusera pas de le lâcher de l'exécuter. Est-ce que ça a du sens? Non, ça ne va pas. Traitez-le.

Answer 5

Il est raisonnable d'avoir également des fichiers binaires dans le contrôle de version:

• Cela évite les problèmes de reconstruction pour les personnes qui utilisent uniquement le binaire.

• Le binaire est cloué lorsque vous relâchez.

Pour que cela fonctionne, le binaire doit toujours correspondre aux sources. Donc, si vous avez fusionné des sources, vous devez reconstruire le binaire à partir d’eux, choisir l'un des fichiers binaires des versions fusionnées ne fera pas l'affaire.

Answer 6

Assurez-vous que la propriété svn: mime-type est définie sur application / octet-stream ou un autre type de texte autre que du texte dans vos dlls.

svn propget *.dll
svn propset svn:mime-type application/octet-stream *.dll

Vous devrez toujours résoudre les conflits lorsqu'ils surviennent.

Et vérifiez la Chapitre sur le type de contenu de fichier de la documentation.

Answer 7

Ainsi, si vous avez les fichiers * .dll dans un dossier séparé, il est beaucoup plus facile de procéder comme suit:

1. Avant de créer votre changement, mettez à jour votre dossier * .dll, mettez également à jour vos sources, si vous avez confiance, afin que vos collègues ne commettent que du code source compilable. (en cas de conflit (quelle serait votre faute à ce moment-là, car vous avez modifié quelque chose avant la mise à jour vers la dernière révision))
2. Faites votre build.
3. Validez directement le résultat.

Alternativement:

ne construisez pas le chemin du répertoire, construisez quelque part à l'extérieur, jusqu'à ce que vous soyez satisfait du résultat.

Procédez ensuite comme suit:

1. Mettez à jour votre copie de travail du dossier dlls (en cas de conflit, c’est votre faute et résolvez-le en "gardez le leur")
2. Copiez vos fichiers .dll de travail dans la copie de travail
3. Informez vos collègues que vous allez commettre une nouvelle révision (vous pouvez laisser cette étape de côté)
4. Engagez votre travail s'il y a un conflit, c'est de leur faute.

Vous avez maintenant deux possibilités:

5a. Vous êtes une personne très détestable et résolvez le problème en gardant le mien.

5b. Vous travaillez comme il se doit ... Lisez le fichier journal et découvrez qui a également validé le temps pendant lequel vous avez eu besoin de copier votre travail dans le dossier, puis vous avez appuyé sur commit. Parlez à ce collègue. Convenez des mesures à prendre.