Subversion et révisions mixtes: recette pour les versions brisées?

Question

Je reviens tout juste à subversion après avoir utilisé TFS pendant un certain temps et généralement je suis tout à fait sorti :)

Il ya une chose que je me souviens différemment. Je ne me souviens pas d'être capable de commettre à partir d'une copie de travail périmée. Ou peut-être que ma mémoire me manque juste sur la définition de "périmé". Je pensais que «périmé» signifiait que tout fichier avait été touché depuis la dernière mise à jour de ma copie de travail, et pas seulement qu'un fichier que j'avais touché localement avait été touché (ce que j'appellerais un conflit).

La raison pour laquelle je vois cela comme un problème est qu'il est très facile de "casser la construction" si je peux commettre mes changements sans d'abord intégrer avec les modifications apportées par d'autres.

Alors est-ce que cette chose mélangée-révisions a été ajoutée ou est-ce juste moi?

Answer 1

Réponse courte: En règle générale, il est conseillé de créer des générations destinées à quitter les bureaux du développeur à partir d'une étiquette fraîchement récupérée. Si possible, sur une machine séparée.

Si vous suivez cette règle, vous pouvez mieux dormir.

Réponse un peu plus longue: Cela signifie que, avant de publier une version, vous devez mettre à jour votre copie de travail, la construire, exécuter tous les tests et, lorsque vous êtes satisfait, en faire une copie. Puis demandez à la machine de construction de faire une construction à partir d'une nouvelle extraction de cette étiquette. Le résultat de la construction que vous transmettez au service de test.

Si vous avez besoin de récupérer une version spécifique ultérieurement, vous avez toujours cette balise à extraire. Si cette version est étiquetée "tags/release_4.2.0" et que vous devez faire un correctif, copiez le tag dans une branche ("branches/release_4.2.1") et corrigez-le. Lorsque vous êtes sûr que cela fonctionne comme prévu, déplacez la branche sur "tags/release_4.2.1". Encore une fois, demandez à la machine de construction de cocher cette balise, de compiler le code et de le remettre aux tests.

Answer 2

La possibilité de procéder à une telle révision «mixte» ne me semble pas intrinsèquement dangereuse. Même si vous utilisez un VCS qui nécessite que tous les fichiers soient complètement à jour avant de faire un commit, le VCS ne pourra pas vérifier que vous avez réellement compilé le code ou exécuté tous les tests unitaires. Ce genre de chose devrait être couvert par un disciple du développeur et un système d'intégration continue.

Subversion a une vision du monde très centrée sur les fichiers, tout comme son ancêtre CVS. Vous pouvez extraire une révision spécifique d'un fichier spécifique sans toucher aux fichiers qui l'entourent. Ceci est en contraste avec d'autres systèmes tels que Git (je ne suis pas familier avec les spécificités de TFS) où les révisions spécifiques extraites de fichiers individuels ne sont pas suivis. Au lieu de cela, l'ensemble du contrôle est une vue du référentiel à un point spécifique de son histoire, et tout écart par rapport à celui-ci est considéré comme de nouveaux changements. Bien sûr, vous êtes toujours libre de commettre autant ou aussi peu de ces nouveaux changements que vous le souhaitez, avec la possibilité de casser la construction si vous ne choisissez pas la bonne combinaison.

Answer 3

Il vous est, car il a toujours été comme ça ;-)

Votre engagement échouera si l'un des éléments que vous essayez de commettre est hors de ce jour, et le dépôt a un général 'numéro de révision, mais tant que tout ce que vous allez commettre est à jour, vous pouvez vous engager. Cela ne veut pas dire que c'est une bonne pratique bien sûr.

Rappelez-vous que svn n'est pas seulement utilisé dans le développement logiciel. En général, cette capacité est probablement agréable à avoir.

En outre, AFAIK TFS fonctionne très similaire à cet égard, non?

Answer 4

Non, vous ne pouvez pas valider les fichiers svn périmés. Lire ceci: http://subversion.tigris.org/faq.html#wc-out-of-date

Answer 5

Merci d'avoir éclairci cela les gars. En y réfléchissant, je suppose que ce que je proposais serait implémenté côté client de toute façon .. et je comprends totalement que ce serait encore aux développeurs de s'assurer que tout se compile. En réalité, cela n'a pas été un énorme problème, mais il y a eu plusieurs fois où un développeur a engagé un travail sans avoir d'abord mis à jour sa copie de travail, ce qui a entraîné une révision de la tête cassée.

Sur une note de côté, que diriez-vous cet exemple de tortue. http://tortoisesvn.net/node/13

« Maintenant, si vous modifiez Fichier2 et essayez de commettre, il échoue, le client indique au dépôt que Fichier2 est à la révision 2 avec des modifications locales , mais le dépôt est déjà à la révision 3. Si vous faites ensuite une mise à jour, File2 sera également à la révision 3 (et bien sûr vos modifications locales seront toujours là). "

Je ne reçois pas réellement le message "obsolète", mais vous devriez penser que cela aurait été le cas à un moment donné?