Montage sur place, contrôle de version - quelle est votre solution?

Question

J'utilise SVN pour des tâches de développement, mais de nombreux fichiers sont encore gérés avec RCS, car il ne semble pas raisonnable de les modifier dans ma copie de travail du référentiel SVN privé (car ce ne sont souvent que des fichiers de configuration qui sont également mieux testés. en place). De plus, il ne semble pas raisonnable de disposer d’une copie de travail du référentiel chaque fois que des fichiers doivent être placés sous le contrôle de SVN. C’est pourquoi je n’utilise que RCS à la place.

Quelle est votre approche pour gérer les fichiers qui, idéalement, ne doivent pas être déplacés / sont édités et testés sur place?

Pour être plus précis: j'aimerais avoir l'équivalent de

• ayant un fichier.txt protégé en écriture
• une commande du type "co-l fichier.txt" (RCS) pour le rendre éditable
• la possibilité de le modifier et de le tester immédiatement
• une commande du type "ci -u file.txt". (RCS) pour enregistrer le changement, ajouter un commentaire et le rendre à nouveau en lecture seule
• les autres utilisateurs devraient également pouvoir le faire au même endroit
• mais, les informations de version doivent aller dans un endroit sûr (probablement le svn rep), sur un serveur différent

Answer 1

J'utilise des systèmes de fichiers de copie (CoW) tels que Ext3cow (avertissement, je suis l'un de ses contributeurs ) pour gérer beaucoup de choses. Par exemple:

• Utilisation d'instantanés pour restaurer des référentiels entiers, quel que soit leur type. Par exemple, si je bousille complètement un arbre git, je peux cp -dpfR ./@123456789 ./, qui remplace mon référentiel de travail par des fichiers tels qu’ils étaient à l’époque 123456789.
• Utiliser les versions / instantanés comme son propre VCS immuable, idéal pour / etc et d’autres choses. Comme les fichiers antérieurs ne peuvent pas être supprimés ou modifiés, chaque capture instantanée est une révision immuable d'un fichier unique ou de l'arborescence complète dans le temps.

En règle générale, j'utilise Git ou Mercurial plutôt que Subversion car je préfère un VCS distribué, mais j'insiste maintenant pour conserver mes référentiels sur un système de gestion des versions localement.

Pour les utilisateurs de Windows, je pense qu’il existe des implémentations portables de la même manière, réalisées complètement en python ... mais pas vraiment sûr.

Answer 2

Comme indiqué précédemment, vous essayez d'utiliser SVN pour quelque chose qui devrait utiliser un DVCS tel que git ou Mercurial.

Tout le monde peut avoir son propre référentiel, puis le synchroniser avec le référentiel central (comme le référentiel SVN).

C’est en fait ce que j’utilise dans mes propres projets.

La seule chose que je n’ai pas comprise, c’est pourquoi vous avez besoin de verrous. Un fichier n'a pas besoin d'être en lecture seule. Vous pensez probablement de cette façon à cause de la fusion de SVN (vous devez presque toujours le faire à la main). Git fait vraiment de la magie [1] et la majorité des fusions se font sans intervention humaine.

[1] Ok, ce n'est pas magique. Alors que SVN se soucie des fichiers, Git se soucie des morceaux de code. De cette façon, il peut fusionner un fichier modifié deux fois en même temps, à condition de ne pas modifier exactement le même bloc de code.

Answer 3

Les systèmes de contrôle de version distribués modernes tels que Git, Mercurial ou Bazaar sont le meilleur outil dans une situation comme celle-ci. Pas à cause de l'aspect distribué (ce qui n'est clairement pas crucial ici), mais parce qu'il est extrêmement facile de créer un référentiel sur place.

Dans Mercurial, il vous suffit de faire:

cd ~/directory
hg init

Avec Git, c'est pareil:

cd ~/directory
git init
git add .

Chaque copie de travail est un référentiel complet. Vous pouvez également la transférer sur le serveur distant en tant que sauvegarde. De plus, toutes les données du référentiel sont stockées dans un seul répertoire caché, ce qui vous évite d'avoir des tonnes de répertoires .svn partout.

J'utilise Mercurial pour gérer / etc sur mes serveurs et je trouve cela extrêmement pratique. Une chose à noter, cela ne marquera pas votre fichier en lecture seule (comme RCS), mais je considère cela comme un avantage.

Answer 4

Vous devez comprendre que les référentiels SVN sont gratuits. Vous pouvez en créer autant que vous le souhaitez.

Vous devez également vous rendre compte que vous ne devez pas extraire un référentiel entier. Vous avez dit:

  

Cela ne semble pas non plus raisonnable de   avoir une copie de travail du référentiel   partout où il y a des fichiers à mettre sous   Contrôle SVN

Je ne suis pas sûr de ce que vous essayez vraiment de faire, mais j'ai l'impression que vous utilisez SVN d'une manière particulière.