Dans le contrôle de version centralisé, est-il toujours bon de mettre à jour souvent?

En admettant que:

• Votre équipe utilise le contrôle de version centralisé.
• Vous travaillez sur une fonctionnalité plus grande qui prendra plusieurs jours et vous ne pourrez pas valider avant car cela casserait la construction.
• Les membres de votre équipe commettent chaque jour quelque chose qui pourrait modifier certains des fichiers sur lesquels vous travaillez.

Comme il s'agit d'un contrôle de version centralisé, vous devrez mettre à jour votre paiement local à un moment donné: au moins une fois juste avant de valider la nouvelle fonctionnalité.

Si vous ne mettez à jour qu'une seule fois juste avant votre commit, il peut y avoir beaucoup de conflits en raison des nombreux autres changements apportés par vos coéquipiers, ce qui pourrait être un monde difficile à résoudre en une seule fois.

Ou, vous pouvez mettre à jour souvent, et même s'il y a quelques conflits à résoudre de jour en jour, cela devrait être plus facile à faire, petit à petit.

Souhaitez-vous rester c'est toujours une bonne idée de mettre à jour souvent?

Personnellement, je mets à jour quotidiennement mes versions locales.

Dans le scénario que vous décrivez, j'irais plus loin en

• Création d'une branche pour la nouvelle fonctionnalité longue.
• Fusionnez souvent de la ligne principale vers cette nouvelle branche.

Par ici,

• Vous pouvez vous enregistrer quotidiennement pour conserver votre code sur le serveur
• Vous n'avez pas à vous soucier de casser la construction en vous enregistrant.
• Vous pouvez utiliser le référentiel pour annuler un travail ou effectuer une différence si nécessaire avec des archivages antérieurs.
• Vous êtes certain de travailler sur la dernière base de code et de détecter très tôt d'éventuelles modifications de code conflictuelles.

Les inconvénients tels que je les vois sont

• La fusion à partir de main doit être effectuée manuellement (ou par script)
• Il faut plus "d'administration"

Oui, c'est une bonne idée de mettre à jour souvent. Vous mettez souvent à jour pour éviter les conflits de fusion difficiles et ce sont les bases de la connaissance de la gestion de la configuration logicielle (SCM) avec le problème des changements divergents.

Cela indépendamment du fait qu'il soit centralisé ou distribué; plus vous divergez d'une source en amont (c'est-à-dire s'il s'agit d'un tronc, d'une branche ou d'un autre référentiel dans le cas DVCS), plus les risques de conflits de fusion sont élevés. Oui, de mauvaises surprises de votre équipe peuvent survenir lors de la mise à jour, mais le report de la mauvaise surprise est encore pire (plus vous attendez, moins les gens se souviennent pourquoi un ensemble de modifications a été effectué).

Pour que la mise à jour fonctionne, cela signifie également que vous et les autres programmeurs travaillant sur le code ne devez jamais valider ou pousser sciemment le code en amont qui rompt la génération . C'est généralement la raison pour laquelle les programmeurs se branchent (ou divergent de l'amont en termes de SCM), pour protéger les membres de votre équipe et les autres parties prenantes contre le code cassé si une telle situation devait inévitablement se produire.

Le mantra que vous pouvez utiliser pour vous souvenir est le suivant: "mise à jour, mise à jour, mise à jour, validation". Assurez-vous toujours que vos modifications fonctionnent avec les autres avant de vous engager. C'est également pour vous assurer que la vérification du code pour la première fois fonctionne également.

Le troisième point de la question est tout simplement faux :

• Vous travaillez sur une nouvelle fonctionnalité qui prendra sûrement plusieurs jours et vous ne pourrez pas valider avant car cela casserait la construction.

Si vous savez que vous allez travailler sur quelque chose que vous ne pouvez pas valider pendant un certain temps, c'est l'exemple de manuel d'utilisation des branches.

Ne vous mettez pas dans la situation où vous avez beaucoup de changements en attente. Si vous savez que vous ne pourrez pas vous engager dans la branche principale de votre projet pendant un certain temps, alors travaillez sur une autre branche. Et là, engagez-vous souvent .

Si vous êtes déjà dans la situation décrite dans la question, passez maintenant à une branche , validez vos modifications et continuez à travailler dans cette branche.

Normalement, dans CVCS, c'est une bonne idée de mettre à jour souvent. Mais si vous travaillez sur une branche, la question de "mettre à jour souvent ou non" devient "fusionner souvent ou pas". Et la réponse est oui de toute façon. Assurez-vous simplement de valider toutes les modifications en attente (dans la branche) avant de fusionner à partir d'une autre branche, à votre option pour annuler la fusion en toute sécurité si vous le devez.

Je pense que vous devriez vous engager plus souvent. Si vous allez travailler pendant longtemps, comme quelques jours, vous devez brancher votre code et travailler dans votre branche plutôt que de travailler directement dans le coffre. Je sais qu'il est pratique de commencer à travailler sans succursales, mais ce n'est pas vraiment flexible car vous ne pouvez pas être sûr que votre mise à jour / validation casserait votre code ou non, ce qui aboutit à la situation où vous maintiendrez votre mise à jour / validation jusqu'à ce que vous ayez fait votre travail. La "ramification de fonctionnalités" est meilleure dans la façon dont vous pouvez toujours valider votre code et fusionner juste plus tard lorsque vous aurez terminé.

Dans la stratégie de branchement, la mise à jour est remplacée par une fusion à partir du tronc. D'après mon expérience, vous n'avez pas besoin de fusionner à partir du tronc aussi souvent, car le code dans quelque chose comme une période de cinq jours ne changerait pas beaucoup et il est plus facile de résoudre le conflit une seule fois une fois que vous avez terminé.

En fait, je trouve plus pratique d'utiliser localement un contrôle de version distribué. Autrement dit, j'utilise git comme client subversion. Cela présente les avantages suivants:

• Les modifications locales sont enregistrées avant la mise à jour, donc si je fais une erreur dans la fusion, je peux toujours revenir en arrière et recommencer.
• Lors de modifications plus importantes, je peux enregistrer les pièces terminées. Cela facilite l'examen des modifications en cours.
• Lorsque je corrige un bogue pendant un travail plus important, je peux valider ce correctif, valider temporairement le reste et "commettre" le correctif pour subversion tout en gardant les autres travaux en cours locaux.

Si vous ajoutez une nouvelle fonctionnalité, pourriez-vous créer un nouveau fichier source unique (et un fichier d'en-tête d'interface externe correspondant)?

Je crains qu'une "nouvelle fonctionnalité" ait des implications généralisées? L'orientation des objets n'est peut-être plus le mot à la mode qu'elle était autrefois, mais ce paradigme a du mérite.

De cette façon, vous pourriez créer le cadre (interface externe, plus les fonctions de stub) et vous engager à ce qu'il y ait un minimum d'effets tiers, pendant que vous terminez le reste de votre développement?

Dans la situation que vous décrivez, je pense qu'il vaut mieux avoir plus de fichiers source plus petits que moins de fichiers plus gros.

En quoi est-il différent pour un contrôle de version centralisé que pour un contrôle distribué?

Dans les deux cas, vous devrez vous enregistrer dans un endroit dont le contenu aura bougé par rapport à ce que vous avez commencé. Je ne vois aucune différence dans la fréquence de fusion du référentiel central vers votre lieu de travail (et votre branche de projet est votre lieu de travail).

J'ai tendance à être souvent pour la fusion (au moins une fois par jour, je peux également fusionner à un autre moment opportun pour moi, ou quand je sais que quelqu'un a vérifié quelque chose qui a un impact sur ce que je travaille). Il est beaucoup plus facile d'absorber de petits changements et si vous avez un problème, les gens sont plus utiles lorsque vous leur demandez ce qu'ils viennent de vérifier que ce qu'ils ont enregistré il y a une semaine.

BTW, je ne sais pas ce que vous appelez "casser la construction". J'ai tendance à travailler par incrément relativement petit, de sorte que je garde un état compilable, même s'il casse certaines fonctionnalités. Et je lance les tests pour savoir que la fusion n'a pas cassé quelque chose qui devrait fonctionner. Encore une fois, il est plus facile de résoudre un problème lorsqu'il est détecté tôt.

Cela dépend de votre capacité à "ne pas mettre à jour" quand quelqu'un d'autre casse la version. D'une part, vous souhaitez mettre à jour le plus petit possible. Personnellement, je mets à jour presque chaque fois que je constate que des mises à jour sont disponibles. D'un autre côté, si la construction se brise et que quelqu'un d'autre prendra un jour pour le réparer, vous voulez toujours pouvoir travailler sur votre nouvelle fonctionnalité dans l'intervalle.

J'ai travaillé avec des systèmes de contrôle de version qui sont très difficiles à sauvegarder une fois la mise à jour terminée. Sur ceux-ci, j'ai tendance à mettre à jour juste avant de devoir m'enregistrer. Avec de meilleurs systèmes de contrôle de version, il n'y a pas de raison de ne pas mettre à jour plusieurs fois par jour.