Contrôle de version basé sur le stockage portable?

9

Je développe des projets personnels sur deux machines sans utiliser de serveur partagé ou de connexion réseau entre les deux.

Des systèmes de contrôle de version courants prennent-ils en charge de manière fiable l'utilisation du stockage portable (tel qu'un périphérique flash USB) comme référentiel partagé?

version-control billpg
la source
Pourquoi voulez-vous / devez-vous utiliser le stockage portable?
Bernard
Pour déplacer du code entre deux machines de la même manière qu'un système de contrôle de version normal le fait avec un serveur partagé. (Je n'ai pas de serveur partagé.)
billpg
J'avais l'habitude d'utiliser un ensemble de référentiels mercurial sur une clé USB pour mettre à jour les outils de fabrication en usine et cela fonctionnait très bien. Vous pouviez même voir quand les techniciens sur place avaient modifié le code sur la machine locale pendant que vous étiez absent, et fusionner (ou rejeter) leurs modifications avant de synchroniser leurs modifications sur le lecteur flash.
Mark Booth
Il est déjà dit ici que SVN prend en charge le stockage local et vous pouvez utiliser USB. Mais je préfère stocker sa base de données dans mon dossier DropBox privé;) Vous pouvez également utiliser de nombreux services gratuits (comme assembla ou tfs.visualstudio.com)
Pavel Voronin

Réponses:

31

Utilisez un DVCS tel que Git ou Mercurial .

Les systèmes de contrôle de version distribués n'ont pas de serveur central partagé.

Avec un DVCS, chaque copie d'un référentiel contient l'historique complet - tout. Cela signifie que lorsqu'elles sont utilisées sur une clé USB, toutes les modifications que vous apportez sont apportées au référentiel sur la clé USB et lorsqu'elles sont déplacées d'un ordinateur à l'autre, cet historique sera conservé.

Oded
la source
9
Et si vous utilisiez github, vous n'auriez même pas à transporter une clé USB
CamelBlues
Je vous remercie. Peut-il être configuré pour utiliser un stockage portable comme référentiel?
billpg
@billpg - Oui. Il vit simplement dans une structure de répertoires.
Odé le
@CamelBlues ou bitbucket ou kilnhg ou probablement divers autres qui peuvent ou peuvent ne pas être appropriés ...
Murph
3
J'ai mes principaux dépôts personnels Mercurial sur DropBox. Fonctionne très bien et implémente automatiquement la sauvegarde (car il est peu probable que DropBox disparaisse en même temps que je perds tous mes ordinateurs).
David Thornley
7

Outre GIT, Mercurial, etc. suggéré ci-dessus, jetez également un œil à Fossil - Il présente les avantages que les binaires d'exécution sont petits (environ 1 Mo pour Windows et Linux), une installation portable et zéro nécessaire. Par conséquent, contrairement aux autres (pour autant que je sache), il peut être placé sur le périphérique de stockage et exécuté sur n'importe quelle machine sur laquelle le stockage est branché, sans avoir à installer l'application sur la machine. Il comprend un Wiki et un système de suivi des modifications / défauts avec le repo. Il a également un gui intégré.

Je ne l'ai pas utilisé sérieusement (j'utilise principalement GIT), mais j'ai été impressionné par son approche légère et l'inclusion d'un Wiki et d'un tracker de défauts le rend idéal pour les petits projets. Ma seule préoccupation était que certaines des fonctionnalités les plus puissantes de GIT pourraient ne pas être possibles, et contrairement à GIT, la communauté d'utilisateurs n'est pas si grande qu'il est facile de trouver des réponses aux questions.

mattnz
la source
Bien que Git prenne le commandement Unix pour faire une chose et le faire bien au sérieux, vous pouvez avoir ces fonctionnalités dans Git à travers des extensions comme ticgit (système de ticketing) et gollum (wiki basé sur le référentiel).
Jason Lewis
@Jason Lewis: Vous avez raison, et comme il est open source, vous pouvez simplement le modifier pour répondre à vos besoins de toute façon, de sorte que GIT (ou tout autre outil) peut être tout pour tout le monde (qui peut être dérangé, a le temps libre et les ressources pour télécharger, installer et déboguer tous les "plugins". Tout ce que je disais, c'est pour une solution qui "fonctionne tout
seul
1

L'utilisation d'un DCVS est probablement une bonne idée, mais ce n'est pas la seule option.

J'ai un petit référentiel CVS sur une clé USB. Lorsque je veux y accéder, il me suffit d'utiliser cvs -d <path>ou de définir $CVSROOTle chemin de la racine du référentiel (ce qui nécessite bien sûr que la clé USB soit montée sur le système).

Si vous êtes déjà habitué à utiliser CVS, cela devrait être réalisable. La même chose devrait s'appliquer à SVN. Cela signifie simplement que votre référentiel central est sur la clé USB et n'est pas toujours visible.

Il existe des arguments pour utiliser un DCVS plutôt que CVS en général. Je ne pense pas que ces arguments soient particulièrement affectés par le fait que le référentiel central se trouve sur une clé USB ou ailleurs. Par exemple, vous pouvez tout aussi facilement créer un référentiel git sur la clé USB.

Keith Thompson
la source
1
Je ne suis normalement pas un grand fan de DVCS, mais je pense que DVCS serait mieux dans ce cas. Le problème avec VCS non distribué est que le dépôt est un point de défaillance unique. S'il se trouve dans un centre de données à température contrôlée et qu'il est sauvegardé régulièrement, ce n'est pas grave - mais quelque chose comme une clé USB sera perdu (ou piétiné, ou mangé par un chien, ou tombé dans un Russe blanc) plus tôt ou plus tard.
Mike Baranczak
1
@MikeBaranczak: Bon point - mais tout ce qui se trouve sur une clé USB doit être sauvegardé régulièrement, que ce soit un référentiel CVS ou non.
Keith Thompson
avec un système distribué, chaque client a déjà une copie complète du dépôt. Il n'y a donc aucune raison pour une procédure de «sauvegarde» distincte.
Mike Baranczak
1
@MikeBaranczak: Bien sûr, c'est une bonne raison d'utiliser un DCVS. Mon point est que le choix d'un DCVS par rapport à un système centralisé ne dépend pas de l'utilisation ou non d'une clé USB.
Keith Thompson
0

En complément des autres réponses:

Bien qu'un DVCS réponde très bien à ce problème, vous pouvez également utiliser Subversion, si vous vous sentez plus à l'aise avec. Subversion peut utiliser un répertoire local au lieu d'un serveur central. Vous pouvez simplement mettre cela sur une clé USB et l'utiliser.

L'inconvénient, par rapport à un DVCS, serait que vous ne pouvez travailler qu'avec Subversion (c'est-à-dire valider, afficher les journaux, etc.) pendant que la clé USB est branchée. De plus, il doit toujours s'agir de la même clé USB (ou au moins d'une clé USB) à jour), car avec Subversion, vous ne devez pas utiliser plus d'un référentiel (c'est la partie non distribuée). Donc, si vous oubliez votre clé USB, vous ne pouvez pas l'utiliser, contrairement à Git ou Mercurial.

Remarque:

Comme expliqué ci-dessus, et dans les commentaires, un DVCS est vraiment mieux adapté à votre problème. Je n'ai mentionné Subversion que par souci d'exhaustivité et au cas où vous auriez une raison particulière d'utiliser Subversion.

sleske
la source
1
Comme pour la réponse de Keith , le problème avec un VCS dans un répertoire local est qu'il s'agit d'un point de défaillance unique. De plus, si vous passez de la machine A à la machine B mais que vous laissez la clé USB branchée sur la machine A, vous êtes beaucoup moins susceptible de vous soucier si vous utilisez un DVCS (vous pouvez toujours fusionner vos modifications locales plus tard) alors qu'avec un VCS , vous devez retourner à la machine A, récupérer le lecteur et revenir à la machine B avant de pouvoir continuer.
Mark Booth
@MarkBooth: Je ne préconise pas cette solution, je voulais juste souligner qu'elle existe, par souci d'exhaustivité et dans le cas où OP a des préférences spéciales pour Subversion. J'ai modifié ma réponse pour que ce soit clair.
sleske
Merci @sleske, je suis d'accord qu'une préférence pour svn(ou même les CV) pourrait peser en faveur de l'utilisation de cette solution, mais dans l'intérêt d'une divulgation complète, les inconvénients de cette approche doivent également être mentionnés. N'hésitez pas à modifier les points de mon commentaire dans votre réponse. Si vous le faites, je serais heureux de nettoyer (supprimer) mes commentaires. * 8 ')
Mark Booth
Je ne sais pas ce que cette réponse ajoute que je n'ai pas déjà dit dans la mienne.
Keith Thompson
1
@KeithThompson: Il ajoute les informations selon lesquelles SVN peut utiliser un répertoire local au lieu d'un serveur central. Cela est expliqué dans les documents SVN, mais comme la plupart des gens utilisent SVN via un serveur central, il n'est peut-être pas évident que SVN ne nécessite pas de serveur.
sleske