Comment puis-je éviter les fusions compliquées dans Subversion ?

Question

Je suis nouveau sur Subversion (SVN) et viens d'un arrière-plan Visual Source Safe (VSS).Dans VSS, la personne qui modifie un fichier extrait le fichier et empêche les autres utilisateurs de le modifier via Visual Studio.Je comprends que SVN est un modèle simultané permettant à plusieurs personnes de travailler sur le même fichier et de fusionner ultérieurement les modifications.Ma question est la suivante :

1. Quelle est la meilleure approche pour éviter que les utilisateurs éditent le même fichier (écrivant des tonnes et des tonnes de code) et soient confrontés à une fusion compliquée pour leurs modifications ou, pire encore, à écrire une tonne de code pour constater que le fichier est verrouillé par un autre utilisateur ?

2. Existe-t-il un moyen d'avertir un utilisateur lors de la récupération d'un fichier qu'il est en cours de modification par un autre utilisateur ou qu'il est actuellement verrouillé par un autre utilisateur ?

Autres détails:

Utilisation du serveur VisualSVN comme serveur SVN.
Utilisation des clients TortoiseSVN et AnkhSVN.

Answer 1

Je suis aussi un ancien utilisateur Visual Source Safe. Fusionne utilisé pour me rendre fou jusqu'à ce que je compris que ce n'est pas un problème technologique, mais une question de personnes. Lorsque vous utilisez VSS, la plupart des développeurs essaient d'obtenir autant que possible le travail accompli, avant de devoir vérifier dans le code. Ce comportement est ce qui contribue à des fusions compliquées.

Voici quelques petites choses à atténuer ceci:

• Toujours mettre à jour votre copie de travail avant de commencer
• Arrivée souvent. Cela rendra le code change plus petit, ce qui sera plus facile à auto-fusion
• Ne laissez pas le code de travail sans contrôle
• Les développeurs devraient créer leur propre branche, si les modifications prendront plusieurs jours ou plus

Ces choses ont aidé énormément, d'autant plus que les équipes que je travaillais continué à obtenir de plus en plus. Le comportement de verrouillage Réplication de VSS est une très mauvaise idée, et causera plus de problèmes. Il suffit de saisir le nouveau flux de travail.

Si vous voulez continuer à utiliser un outil, alors je suggère que vous regardez SVNMonitor .

Answer 2

Je voudrais proposer une approche différente pour utiliser la subversion.

• Vous devriez obtenir des mises à jour fréquemment.
• Vous devriez également vérifier au début et souvent.

Avec cette approche, la fusion est généralement peu fréquente et se fait automatiquement. Dans le cas des conflits, ceux-ci sont souvent plus petits.

Answer 3

Un couple de points que j'ai rencontré à un endroit précédent, où nous sommes passés d'un système de verrouillage à SVN.

Il est pas vraiment une bonne idée d'essayer de reproduire le comportement de verrouillage modifier déverrouillage dans SVN comme il a été conçu de telle sorte que vous n'avez pas besoin de travailler de cette façon. Les algorithmes de fusion utilisés par SVN sont très bons et je n'ai rencontré quelques occurrences où une intervention manuelle lors d'une fusion était nécessaire. Il est étonnamment rare que deux personnes travaillant sur le même fichier sera réellement toucher la même ligne (s) et celui-ci est souvent le seul moment où une intervention manuelle est nécessaire.

SVN est vraiment conçu pour être utilisé dans un environnement où vous mettez à jour à partir du tronc ou votre succursale souvent. Si vous devez faire un travail à long terme ou de travail qui change beaucoup de code dans un fichier, vous pourriez être mieux d'utiliser une branche pour faire le travail et la fusion qui avant. Oui, vous devrez passer par une fusion la douleur de temps en temps, mais il est beaucoup moins de douleur que vous obtenez avec un système qui n'a pas été conçu pour fonctionner de cette façon.

Si vous essayez d'utiliser SVN non pas comme « SVN native », mais comme VSS avec un nom différent, il sera douloureux et il ne sera pas en vaut la peine. Familiarisez-vous avec le nouveau paradigme et vous serez surpris de voir combien il est plus agréable de travailler de cette façon par rapport à l'ancienne « un seul utilisateur édite un fichier donné à un moment donné » routine.

Answer 4

D'abord, il est probablement sage d'éviter d'écrire « des tonnes et des tonnes de code » sans vérifier les fichiers, si possible. Si vous avez une bonne suite de tests unitaires (et sinon, pourquoi pas? :), puis aussi longtemps que vous archivez sur la barre verte, commits fréquents sont les meilleurs.

Alors, si vous avez des changements qui prennent beaucoup de temps par nécessité, il vaut la peine de faire un svn update périodiquement pour rester en phase avec le tronc le plus près possible. Subversion est assez respectable à la fusion (par rapport à VSS) et se chargera de la majorité des choses bien.

Tout ne peut pas gérer, il sera mis dans un état conflictuel, vous laissant pour résoudre les conflits avec un outil de fusion de votre choix (je recommande Winmerge pour cela, il est ace).

Answer 5

Le seul moment où vous pouvez utiliser l'ancien modèle de verrouillage de style VSS est avec des fichiers binaires (documents MS-Word, etc.) que vous voulez à la version, mais que SVN ne peut pas fusionner automatiquement les modifications à partir de plusieurs sources.

Answer 6

Pas un problème. En utilisant tortoisesvn, faire ...

1. Dans l'Explorateur Windows, cliquez droit sur le fichier (s).
2. Choisissez "Tortoise SVN" puis « Get Verrouillez ... "
3. Dans la boîte de dialogue de verrouillage des fichiers, remplissez dans votre raison de la serrure.
4. Cliquez sur OK.

Answer 7

Bien que SVN a un verrouillage commande, la façon la plus courante d'utiliser SVN implique l'approche optimiste de verrouillage.

Cela signifie que vous et je peux modifier le même fichier et vous inquiétez pas beaucoup à son sujet (la plupart du temps nous ne serions parce que nous travaillerons sur les différentes parties de notre projet). Si je suis le premier à valider les modifications apportées au fichier, votre commettras tentative échouera. C'est quand SVN vous informera.

Vous devrez alors exécuter la commande « Update », qui (le plus probable) fusionner automatiquement mes changements engagés avec vos changements locaux et puis votre prochain commit tentative passera par.

Pour éviter d'avoir des ennuis avec cette approche optimiste: que d'autres ont suggéré, commettent souvent et ne commettent pas de trop à la fois

Answer 8

  

SVN est un modèle simultané permettant à plusieurs personnes de travailler sur le même fichier, puis fusionner les changements ensemble.

Je pense qu'il est plus de travailler sur le même projet qui se compose d'un groupe de plus ou moins de fichiers indépendants. Travailler sur le même fichier et la fusion des résultats est certainement possible , et ne se produisent chaque maintenant et puis, mais il est certainement pas le mode par défaut / de fonctionnement souhaité. Donc:

• Mise à jour souvent.
• Engagez souvent.
• Évitez les classes / fichiers (1000 lignes est beaucoup trop). Cela a également des avantages supplémentaires: -)

Answer 9

Je prendrais un certain temps d'apprentissage sur le "check in dance"

Voici un jeté dessus.

Il y a aussi plusieurs articles sur le web à ce sujet et comment soulager la douleur.

Answer 10

Réponse courte:

1. Mettez à jour souvent.Enregistrez-vous tôt, enregistrez-vous souvent.Si vous travaillez sur quelque chose pendant plus d'un ou deux jours, envisagez de créer une branche de fonctionnalités.
2. Non.

Réponse un peu plus longue :

Si plusieurs développeurs effectuent « des tonnes et des tonnes de modifications » sur le même fichier, quelque chose ne va pas, soit avec la façon dont vos développeurs travaillent, soit avec la façon dont les fonctionnalités sont réparties sur différents fichiers.J'ai travaillé avec CVS ​​et SVN dans des équipes de différentes tailles et IME, il y a très peu de cas où la fusion devient un réel problème.(Il s'agit généralement de modifications de services fondamentaux tels que les chaînes, la journalisation, la gestion des erreurs, etc.qui nécessitent de changer à peu près tout le code.De tels cas nécessitent une certaine interaction humaine et une planification pour se dérouler sans problème.)

Answer 11

Je suis d'accord avec tout le monde, dans la mesure où possible, vérifier au début et souvent (il est pas toujours possible). Si vous faites quelque chose de complexe et nouveau, il peut être fait sur une branche - la règle applicable, et souvent engager très tôt et où garder votre branche aussi à jour que possible avec le code de la tête.

Dans notre expérience pour la plupart des gens ont tendance à ne pas partie de travailler sur le même fichier ou tout au moins la même partie du fichier en même temps (dans VSS vous ne pouvait pas de sorte que votre travail modèles vous soutiennent probablement déjà dans ce).

Une chose plus clé - assurez-vous que tout le monde utilise les mêmes règles pour l'utilisation des onglets / espacement, pour la mise en page et pour la mise en forme, cela est une bonne pratique de toute façon, mais plus cohérente vous êtes moins vous êtes susceptible de trouver « les différences "entre les fichiers de code qui n'existe pas vraiment.

De plus, je vous recommande d'examiner l'intégration continue-à-dire ayant un serveur de build, cela fournit des avantages considérables en termes de confiance que votre code engagé construira dans un environnement « propre » et, si vous êtes convenablement équipé des tests, vous donnera la confiance futher que cela fonctionne encore -., même après un processus de fusion complexe

Nous utilisons TeamCity que nous avons trouvé excellent - mais il y a autres.