Qu'est-ce qu'un bon modèle d'utilisation Mercurial pour cette configuration?

Question

Nous avons deux développeurs sur le même réseau fermé, un autre développeur à quelques minutes de route et un quatrième développeur à l'autre bout du pays. Le courrier électronique, le ftp et les supports de suppression sont tous des méthodes de transfert possibles pour les personnes ne faisant pas partie du même réseau.

Je suis l'un des deux développeurs de réseaux fermés, nous considérons l'emplacement «maître».

Quelle est la meilleure configuration/modèle Mercurial pour le groupe? Quel est le meilleur moyen de trasmiter les changements de/vers les développeurs distants? Comme je suis en charge, j'ai pensé que je devrais garder au moins un maître repo avec un autre repo local dans lequel je peux développer. Chaque autre personne devrait juste avoir besoin d'un clone du maître. Est-ce correct? Je suppose que cela me rend également responsable de la fusion?

Comme vous pouvez le voir, j'essaie toujours de comprendre le contrôle de version distribué. Je ne pense pas qu'il existe un autre moyen de le faire avec la connectivité.

Answer 1

Les utilisateurs extérieurs au réseau peuvent créer patches et/ou utiliser email pour envoyer les mises à jour au référentiel principal ou à quelqu'un, comme vous, pour les fusionner. Les autres personnes internes peuvent avoir des copies locales, comme vous-même et fusionner, mais si vous les avez en dehors des correctifs réseau, il serait peut-être préférable qu'une personne les traite pour que personne ne soit confus, mais c'est quelque chose que vous devez Considérez-vous.

Synchronisation inverse, vous créez un correctif, et les envoyer par courrier électronique ou obtenir un lecteur flash pour les développeurs à distance pour patcher leur système. Vous allez avoir besoin d'une bonne communication dans l'équipe, je suis reconnaissant de ne pas être à votre place.

Ce sont mes seules suggestions - bien sûr, l'évidence, leur obtenir une connexion VPN! J'aimerais entendre comment ça se passe, quels plans se stabiliser dans un groove hebdomadaire, et cetera.

Answer 2

Correct. Le seul moyen de faire quoi que ce soit sur le réseau fermé est via le lecteur flash.

Answer 3

Les correctifs sont une solution simple et polyvalente.

Pour déplacer des groupes de modifications plus importants (en particulier les changements binaires et les fusions), Mercurial propose des ensembles binaires. Un bundle est essentiellement la substance binaire qui est envoyée sur le réseau lorsque vous faites hg push, mais ici, il est capturé dans un fichier.

Imaginons que j'ai obtenu un clone (lecteur flash, DVD, etc.). Appelez le upstream. Je fais ensuite un deuxième clone, appelez le devel. Je fais tout mon développement en devel et fais beaucoup de commits, fusionne, etc. Depuis que Mercurial est distribué je peux tout faire hors ligne.

Pour voir qui changesets manquent dans upstream je

% hg outgoing ../upstream 

Quand j'ai quelque chose à envoyer, je peux utiliser

% hg bundle changes.hg ../upstream 

pour obtenir un fichier compressé binaire contenant les changesets y compris tous leurs méta-données. Je peux ensuite graver ce fichier sur un CD et l'envoyer par mail ...

Le destinataire du paquet peut faire

% hg incoming changes.hg 

pour voir la liste et changeset

% hg pull changes.hg 

pour décompresser et ajouter les changesets à son dépôt. Il devra alors probablement fusionner - c'est exactement comme s'il avait tiré directement de votre dépôt via HTTP ou SSH.

Notez que le référentiel upstream est uniquement utilisé comme moyen pratique de se souvenir des modifications déjà présentes dans le référentiel en amont. Vous pouvez également noter l'ID de changeset et utiliser hg bundle --base lors de l'empaquetage pour spécifier l'ensemble de modifications de base (commun). Voir hg help bundle ou look in the wiki.