Quels sont les avantages des systèmes de contrôle de version qui versionnent chaque fichier séparément?

15

Au cours des dernières années, j'ai travaillé avec plusieurs systèmes de contrôle de version différents. Pour moi, l'une des différences fondamentales entre eux est de savoir s'ils versionnent les fichiers individuellement (chaque fichier a sa propre numérotation et historique de version) ou le référentiel dans son ensemble (un «commit» ou une version représente un instantané de l'ensemble du référentiel) .

Quelques systèmes de contrôle de version "par fichier":

CVS
ClearCase
Visual SourceSafe

Quelques systèmes de contrôle de version "référentiel complet":

SVN
Git
Mercuriel

D'après mon expérience, les systèmes de contrôle de version par fichier n'ont entraîné que des problèmes et nécessitent beaucoup plus de configuration et de maintenance pour être utilisés correctement (par exemple, "spécifications de configuration" dans ClearCase). J'ai eu de nombreux cas où un collègue modifiait un fichier non lié et cassait ce qui serait idéalement une ligne de développement isolée.

Quels sont les avantages de ces systèmes de contrôle de version par fichier? Quels sont les problèmes rencontrés par les systèmes de contrôle de version "référentiel complet" que les systèmes de contrôle de version par fichier n'ont pas?

version-control

— Mike Daniels
source

3

Je pense que c'est principalement comme ça historiquement et nous nous éloignons maintenant des systèmes orientés fichiers vers des systèmes orientés changements, mais du point de vue d'aujourd'hui, il est difficile de comprendre pourquoi les gens ont même essayé l'approche par fichier. Excellente question!

— blubb

Toutes mes excuses si cette question se présente comme argumentative. C'est le produit d'une frustration récente.

— Mike Daniels

1

@Mike Daniels: Ce n'est pas le cas (du moins pour moi) car vous demandez clairement les avantages.

— blubb

Ces deux points de vue ne sont que des conventions différentes. Tout argument en faveur de l'un sur l'autre ne fait que soulever le contre-argument des partisans de l'autre côté. Par exemple, si vous souhaitez un comportement "rep-entier" dans Clearcase, vous pouvez personnaliser vos spécifications de configuration par date.

— mouviciel

SVN a une version par fichier, ou est-ce que cela a également changé dans la dernière version?

— Klaim

12

D'après mon expérience, il n'y en a pas: le VCS "à référentiel entier" domine strictement le VCS "par fichier".

— Rein Henrichs
source

3

Chaque fichier présente un avantage lorsque vous créez des lignes de produits (plusieurs produits logiciels) à partir du même référentiel.

Certains environnements de contrat client nécessitent la preuve que leur code drop contient UNIQUEMENT les modifications souhaitées, et non d'autres modifications. C'est assez facile si les numéros de version des fichiers sont toujours les mêmes.

Et ce n'est pas un exemple aléatoire que j'ai sorti de nulle part.

Cela s'est produit la dernière fois que j'ai expédié des mises à jour logicielles à l'armée américaine pour un système dont elles avaient acheté un grand nombre à mon ancien employeur. La valeur en dollars des contrats a été mesurée en milliards de dollars (à l'époque où les dollars américains valaient beaucoup plus)

Cela aide donc parfois.

Curieusement: là où je travaille maintenant, nous expédions également à chaque client un livrable différent .... (Et ce n'est pas quelque chose que j'ai décidé, au cas où vous vous poseriez la question.)

Je soupçonne que c'est beaucoup plus courant dans l'espace de défense / aérospatial que dans les applications de film rétractable ou Web.

— Tim Williscroft
source

3

Mais une branche du référentiel de fichiers entier répondrait également aux mêmes besoins. Par exemple, dans bzr, les branches sont complètement indépendantes de la ligne principale jusqu'à votre fusion (ou partage un référentiel).

— edA-qa mort-ora-y le

1

Je ne peux pas penser à une seule situation où une branche dans un système de «référentiel entier» n'exprimerait pas mieux l'état requis que de s'appuyer sur un état externe au VCS pour déterminer quels fichiers utiliser dans un VCS «par fichier». Mon premier travail après avoir utilisé RCS, un tas de scripts pour versionner le projet et un script de haut niveau pour versionner les scripts de version - un cauchemar absolu, et oui, c'était aussi pour un projet militaire. * 8 ')

— Mark Booth

@Mark Booth, le client savait quels fichiers avaient été modifiés pour les correctifs souhaités. L'audit de configuration physique a donc été effectué par numéro de contrôle de version

— Tim Williscroft

Ce que je dis, c'est qu'une version + un correctif audité nécessite des informations différentes à différents endroits, le VCS et les auditeurs. Avec une branche dans le système de «référentiel complet», ces deux états sont enregistrés comme des entités distinctes. Maintenant, les mêmes informations sont dupliquées entre le VCS et le système d'audit et doivent toujours correspondre. gitpeut même faire la différence entre l'auteur et le committer, vous pouvez donc conserver un référentiel «audité» dans lequel vous savez à la fois qui a créé le patch (l'auteur) et qui l'a audité (le committer). Fournissez-nous une situation exemplaire et je vais inverser mon -1.

— Mark Booth

@Mark stand quels correctifs? ils savaient que leur logiciel était cet ensemble de fichiers A 1.01 B 1.05 D 1.55 E 1.44 F 1.01 et le SVD pour la version qu'ils acceptaient avait des informations de changement fichier par fichier, par exemple E changé pour corriger le défaut 1104, ancienne version 1.43, nouvelle version 1.44 . Le ciel nous aide si nous avons changé F de la version 1.01. La situation était encore plus compliquée car il y avait de vrais bugs corrigés, pour lesquels ils ne voulaient pas de changements. Ces personnes voulaient un ensemble minimal de changements, pour ne reprendre que certaines fonctionnalités choisies à la suite d'une année de développement. Sélection de correction de bogue post-hoc.

— Tim Williscroft

3

Il n'y a aucun avantage à la gestion des versions par fichier.

Les inconvénients, en revanche, sont nombreux et manifestes.

— William Payne
source

0

Je pourrais dire que les systèmes de contrôle de version "par fichier" n'ont pas d'avantages clairs autres que la mise en œuvre du VCS. Les codeurs du VCS seraient heureux de coder lorsqu'il s'agissait d'un versionnement "par fichier". Je suis d'accord sur le fait que cela a été soulevé historiquement.

— Arvind Chinniah
source

0

Il n'y a aucun avantage sur l'approche par fichier lorsque vous avez des fichiers associés. Quel est le cas le plus courant dans un environnement de développement.

Dans quelques cas particuliers - / etc ou. les fichiers de votre répertoire personnel sous Unix sont les seuls que j'utilise régulièrement - vous gérez (principalement) des fichiers non liés. Et puis, avoir un système qui insiste pour rester synchronisé avec les changements non liés peut être une nuisance.

— AProgrammer
source