2010-06-05 11 views
6

En utilisant Git ou Mercurial, comment sauriez-vous quand vous faites un clone ou un pull, personne n'enregistre les fichiers (en le poussant)? Il peut être important que:En utilisant Git ou Mercurial, comment sauriez-vous quand vous faites un clone ou un pull, personne n'enregistre les fichiers (en le poussant)?

1) Vous ne savez jamais qu'il est dans un état incohérent, donc vous essayez pendant 2 heures d'essayer de déboguer le code lorsque votre code est dans un état incohérent. 2) Avec tout le code de l'infrastructure (comme Ruby on Rails) - potentiellement des centaines de fichiers - si certains fichiers sont incompatibles avec l'autre, le rake db:migrate ou script/generate controller ne peut-il pas causer des dommages ou des incohérences au code base?

+3

Git et Mercurial ne sont pas le seul VCS qui souffrent d'incohérence. Je peux vérifier le code cassé dans mon dépôt Subversion et vous laisser le code de débogage pendant 2 heures. La communication est la clé! – basszero

+3

communication * est * clé. C'est aussi pourquoi le contrôle des sources n'est qu'un aspect du développement logiciel. –

Répondre

16

Les tirages et les poussées sont atomiques dans Git et Mercurial. Cela signifie qu'ils ne vous permettront jamais d'obtenir des changesets partiellement activés. Vous aurez toujours un ensemble complet de modifications. Mise à jour: Je pensais juste que vous pourriez avoir peur "Que faire si quelqu'un pousse une série de changesets, et je vais en obtenir quelques-uns". Ensuite, il s'agit de la communication et du flux de travail acceptés dans le projet.

Il est souvent convenu que chaque validation dans le coffre (maître ou comment vous l'appelez) doit laisser le code dans un état cohérent. Si quelqu'un sait qu'il apportera des modifications qui créeront des incohérences temporaires, il devrait le faire dans une branche et, s'il est prêt, le fusionner avec le tronc. Ensuite, le tronc est amené à l'état de la branche en un seul commit, donc vous le verrez toujours cohérent.

Mise à jour 2: Comme tonfa l'a dit dans le commentaire - dans Mercurial, la poussée est atomique. J'ai fait un test simple en git, et les poussées sont atomiques ici aussi. Vous n'avez donc pas besoin de craindre de telles incohérences si vous savez que d'autres développeurs utilisent des changesets fonctionnels. (bien que les déclarations antérieures sur les branches soient toujours valables).

+4

Je ne sais pas pour git, mais en hg si quelqu'un pousse plusieurs csets, ils n'apparaissent que lorsque la poussée est terminée, atomiquement (je suppose que git fait de même, en changeant le pointeur au sommet de la branche seulement à la fin), – tonfa

+0

Ah, oui, vous avez probablement raison. – silk

1

Quand je fais une pull dans hg, s'il n'y a aucun changement, je reçois un:

pulling from <REPOSITORY NAME> 
searching for changes 
no changes found 

donc je sais il n'y a pas eu de changements depuis la dernière fois que je tire. De plus, vous pouvez toujours parcourir l'historique du référentiel et voir les modifications qui ont été apportées.

2

Comme d'autres l'ont déjà dit, les commits sont atomiques, donc vous n'aurez pas de problème avec une incohérence due à une validation partielle. Ce que cette réponse ajoute à la conversation est que vous avez la possibilité d'ajouter des hooks de pré-validation qui forcent une exécution propre de la suite de tests avant que la validation ne soit autorisée.

http://git-scm.com/docs/githooks

https://www.mercurial-scm.org/wiki/Hook