Copie d'un répertoire dont la version est contrôlée

Question

Je suis curieux de savoir s'il est acceptable de copier un répertoire sous contrôle de version et de commencer à travailler sur les deux copies.

Je sais que cela peut être différent d'un VCS à l'autre, mais je ne spécifie intentionnellement aucun VCS car je suis curieux de connaître les différents cas.

Je parlais récemment à un collègue de le faire en SVN.Je pense que ça devrait aller, mais je ne suis toujours pas sûr à 100%, car je ne sais pas exactement ce que SVN stocke dans la copie de travail.

Cependant, si nous parlons du monde DVCS, les choses pourraient être encore plus floues, puisque chaque copie de travail est un référentiel en soi.Étant confronté à cela en bzr maintenant, j'ai décidé de poser la question.

Modification ultérieure :

Certaines personnes m’ont demandé pourquoi je voudrais faire ça.Voici toute l'histoire :

Dans le cas de SVN, c'était parce qu'étant hors du bureau, la connexion au serveur SVN était très lente, donc mon collègue et moi avons décidé de vérifier les sources une seule fois et d'en faire une copie locale.C'est ce que nous avons fait et cela a bien fonctionné, mais je me demande toujours si le fonctionnement est garanti ou si c'est simplement arrivé.

Dans le cas bzr, je prévois de déplacer le dépôt "principal" vers un autre serveur.Je pensais donc simplement le copier là-bas et commencer à considérer qu'il s'agissait du dépôt principal.Je suppose que le plus sûr est de faire un clone.

Answer 1

Dans Subversion, chaque dossier .svn contient tout ce qui est nécessaire pour le dossier qui le contient.Et comme tous les chemins locaux sont stockés de manière relative, vous êtes en sécurité lorsque vous copiez des arbres entiers ou partiels en dehors de l'arborescence d'extraction d'origine.Ils continueront à fonctionner dans leurs nouvelles maisons.

Je copie fréquemment des sous-arbres de mon tronc à l'extérieur, je bascule les nouvelles copies vers d'autres branches/balises et je fais tout ce qui est nécessaire sur les copies locales "clonées".De cette façon, si, pour une raison quelconque, je dois revenir en arrière et faire quelque chose dans le coffre, j'ai une copie intacte du coffre à l'emplacement d'origine.

Copie de répertoires contrôlés par la source dans d'autres arbres contrôlés par la source, en revanche, sont peu sûr.Si vous écrasez des dossiers .svn, vous corromprez probablement vos copies cibles.

Answer 2

Je fais cela de temps en temps en SVN et je n'ai rencontré aucun problème.Je crois que dans SVN, tout ce qui est stocké est l'état d'origine du répertoire et un pointeur vers le répertoire du référentiel dont il provient.

Donc, fondamentalement, cela fonctionne comme vous le pensez.

• Si File1 dans Copy1 change et File2 dans Copy2 change, les deux peuvent être validés
• Si File1 dans Copy1 change et File1 dans Copy2 change, celui qui valide en deuxième aura une erreur et devra d'abord mettre à jour/fusionner.

Pour ceux qui sont curieux de savoir pourquoi j'ai dû copier, j'ai eu des problèmes avec les paiements sur notre réseau qui étaient très lents lors de la première vérification d'un de nos plus grands projets.En revanche, le simple fait de copier depuis un autre ordinateur semblait me procurer les mêmes avantages.

Answer 3

En SVN, ce n'est pas un problème.Vous pouvez simplement travailler avec la copie comme si vous aviez effectué une deuxième extraction.

Je recommanderais cependant de vérifier une deuxième fois.Si vous souhaitez une copie sans les fichiers .svn, svn export en créera une.

Answer 4

Pour bzr, si vous copiez simplement le répertoire .bzr vers un autre emplacement, cela fonctionnera.Il ne stocke aucune information sur le chemin dans lequel il se trouve ou sur l'hôte sur lequel il se trouve, vous pouvez donc le copier n'importe où et vous attendre à ce que tout fonctionne correctement.

Answer 5

Je suggérerais que non, car vous contournez le mécanisme de contrôle de source.

Mais peut-être pourriez-vous expliquer « pourquoi » ?

Answer 6

Vous pouvez également simplement consulter deux copies de travail (au moins avec SVN) pour dire work/copy1 et work/copy2 et travailler sur les deux versions en parallèle.

Je me demande cependant ce que vous essayez de réaliser, car la copie n'est peut-être pas la meilleure solution à votre problème.

Answer 7

Cela dépendra du VCS.Je sais dans CVS qu'il stocke des répertoires (cachés) dans chaque répertoire contrôlé par version.Ces fichiers sont bien entendu ensuite copiés avec n’importe quelle copie de ce répertoire.

Il arrive si souvent que vous ne souhaitez PAS copier ces fichiers cachés que l'outil rsync est livré avec une option (-C) pour ignorer ces fichiers de la même manière que CVS.

Answer 8

J'ai eu quelques maux de tête avec SVN lorsque j'ai réorganisé la disposition des dossiers depuis Visual Studio.Un dossier déplacé dans une solution déplacera littéralement le dossier dans le système de fichiers, y compris le dossier caché. .svn dossier.Cela pose des problèmes de validation car le .svn les données sont associées à l'ancien chemin et je n'ai pas trouvé de moyen de se réassocier à son nouveau chemin.SVN clean up fonctionne correctement mais ne répare rien.SVN switch ne vous permet pas de le modifier après le déplacement du dossier.Je n'ai pu résoudre ce problème qu'en supprimant tout .svn dossiers dans le dossier déplacé et ses sous-dossiers, puis ajoutez à nouveau le dossier.

Le problème que j'ai avec ce correctif est que vous perdez votre trace de version sur ces fichiers car SVN le considère comme tout nouveau.De plus, il ne stocke pas le contenu du fichier aussi efficacement en stockant les différences de la version précédente.

Selon la documentation SVN, il est recommandé d'autoriser le svn client pour déplacer/créer/supprimer tous vos dossiers afin de garder tout synchronisé pour la prochaine validation.Ce n'est pas toujours acceptable de la part de Visual Studio.Heureusement, la plupart des cas problématiques sont détectés lors de la validation, en particulier si vous utilisez TortoiseSVN.

Answer 9

Pour SVN, cela fonctionnera généralement comme d'autres l'ont déjà indiqué.

Si vous copiez entre machines, vous rencontrerez probablement des problèmes.Par exemple, si vous accédez à votre référentiel SVN à l'aide de l'URL du référentiel file://, les choses risquent de se briser.Il en va de même pour les URL http:// ou svn:// où l'accès au serveur peut être différent.

Pour rester en sécurité, je passerais simplement à la caisse du nouvel emplacement.Si vous souhaitez avoir de nombreuses modifications non validées dans le nouveau répertoire de travail (généralement une mauvaise idée), vous pouvez alors utiliser rsync pour copier votre source sans introduire les répertoires .svn.

Answer 10

Il me semble que GIT pourrait également répondre à vos besoins, car vous mentionnez être déconnecté ou via une connexion de mauvaise qualité.GIT dispose également d'un très bon support SVN, donc les deux sont complémentaires et vous vous retrouverez avec un joli système de fichiers versionné.