Différents systèmes de contrôle de version distribués travaillant ensemble

Question

Mon bureau dispose d'une installation centrale Source Safe 2005 que nous utilisons pour le contrôle des sources.Je ne peux pas modifier ce que le bureau utilise sur le serveur.

Je développe sur un ordinateur portable et j'aimerais disposer d'un référentiel de contrôle de source local différent qui puisse se synchroniser avec le serveur central (si disponible), quel que soit le fournisseur central.La raison de cette demande est que je puisse maintenir une branche/construction locale stable pour les présentations clients tout en continuant à me développer sans avoir à franchir des obstacles enflammés.De plus, en tant que consultant, mes clients peuvent demander que j'utilise leur fournisseur de contrôle de source et la flexibilité ici rendrait la vie plus facile.

L'un des clients de contrôle de source distribué existants peut-il gérer cela ?

Answer 1

Bien...KernelTrap a quelque chose à ce sujet.On dirait que vous pouvez utiliser vss2svn pour diriger le dépôt Source Safe vers un dépôt Subversion, puis utilisez le très joli git-svn pour l'extraire dans un dépôt git local.

Je suppose que les validations vers VSS ne seraient pas un processus fluide et automatique utilisant cette méthode.

Answer 2

Vous devriez pouvoir consulter la version actuelle du code, puis créer un référentiel git autour d'elle.La mise à jour et la validation dans votre référentiel git local devraient être simples.Tout comme le cloner.

Le seul problème est que vous devez les faire ignorer tous les deux (j'ai fait quelque chose de similaire avec SVN) en jouant avec les fichiers ignorés appropriés.Je suppose que SourceSafe vous permet d'ignorer les choses.Et vous devrez effectuer certaines opérations deux fois (comme dire aux deux que vous supprimez un fichier).

Answer 3

Ce L'épisode de HanselMinutes couvre exactement ce que j'espérais entendre.Apparemment, Git peut être utilisé localement puis attaché à des référentiels externes Subversion/VSS selon les besoins.Ils en parlent pendant 14 à 15 minutes.

Answer 4

un jour, je travaille dans une entreprise qui utilise VSS (et dans d'autres entreprises qui en utilisent d'autres moins inconnues) GDS) mais je préfère utiliser SVN (un jour j'essaierai GIT) pour un développement actif, pour moi et mon groupe.

Tout d'abord, cette situation n'est qu'une bonne idée, si les engagements dans VSS sont peu nombreux sur un mois, car travailler avec d'autres SCM (que VSS) vous donne plus de flexibilité, mais l'engagement dans VSS à partir de SVN coûte cher en temps.

Ma solution était :

VSS -> SVN :J'ai un script Linux (ou un script Ant, ou un script XXX) qui copie le travail actuel du répertoire de mise à jour de VSS vers le SVN actuel, puis actualise le client SVN et met à jour/fusionne/valide sur SVN.Avec cela, vous êtes au courant des changements du reste de l'entreprise qui utilise VSS.

SVN -> VSS :De cette façon, vous avez besoin d'une extraction de tous vos fichiers de modification vers VSS, vous pouvez ensuite simplement utiliser le script inverse pour copier à partir du répertoire SVN de mise à jour actuel (ignorer les répertoires .svn) et copier dans le répertoire VSS de mise à jour actuel, mettre à jour et valider.

Mais rappelez-vous que dans quelques cas, cela vaut la peine de le faire.