Nous avons un seul morceau de code généré automatiquement que nous gardons dans la subversion. Parfois, je travaille sur un morceau du générateur tandis qu'un autre collègue travaille sur une pièce différente du générateur. L'un de nous vérifie et l'autre reçoit le dernier. Maintenant, notre code généré est en conflit. Parce qu'il est généré, il sera correct après la prochaine fois que le générateur est exécuté, mais Subversion l'a signalé comme en conflit. C'est un peu douloureux de faire la douleur, de trouver ces conflits, de vérifier qu'ils sont effectivement dus au code généré, puis manuellement "accepter la mine" pour effacer les conflits.
Y a-t-il un moyen de reconnaître la subversion que pour tous les fichiers d'un dossier donné, je veux juste accepter automatiquement la mienne? J'aimerais rester à l'écart des fichiers de commandes dédiés, car la majeure partie du bureau utilise Tortoise SVN et je cherche une solution que tout le monde peut utiliser.
3 Réponses :
Vous devez probablement éviter d'avoir généré des fichiers dans SVN en premier lieu - comme vous pouvez le dire, il s'agit d'une source de conflits. Mieux de les avoir ignorés et les construire dans le cadre de la construction.
Mais sur votre question, vous devriez pouvoir utiliser le - Accepter l'option Mine-Full à la mise à jour SVN , ce qui rend les conflits résolus automatiquement à la mine. Voir le manuel de subversion et pages de l'homme Pour plus de détails.
Mise à jour SVN --Accept [Payspone | Base | Mine-Full | Leurs-pleines | Modifier | Lancement]
qui devrait être non?
SVN Resolve -R -R -Accept Mine-Full * Sans la marque d'astérisque, j'ai eu "pas assez d'arguments fournis" et notez la -R pour la récursivité.
Soit vous souciez des conflits, vous devez donc les réparer, ou vous ne le faites pas, auquel cas le code généré automatiquement ne doit pas être dans SVN en premier lieu. Svn! = Automatisation du flux de travail.