Comment utiliser Mercurial en tant que développeur isolé?

Question

J'ai décidé que je voulais utiliser Mercurial pour un petit projet personnel.

La plupart de l'aide que j'ai lu à ce sujet parle de fusion de changements entre plusieurs utilisateurs. Puisque je suis en solo, ça n'arrivera pas.

Dois-je avoir plusieurs référentiels? Mon ordinateur de développement est déjà sauvegardé tous les soirs sur mon Windows Home Server, il ne semble donc pas utile d'avoir un deuxième référentiel ailleurs à des fins de sauvegarde.

Devrais-je être ramifié tous les jours? Ou juste autour des versions? Ou lorsque?

En général, quelles pratiques recommandez-vous pour le développeur solitaire utilisant Mercurial?

Answer 1

J'utilise Mercurial pour développer FsCheck, un cadre de tests unitaires hébergé dans CodePlex. Je suis actuellement le seul développeur, mais parfois les gens m'envoient des correctifs.

Concrètement, j'ai un dossier dans mon système de fichiers appelé "FsCheck". En cela, j'ai un dépôt, et donc un dossier, appelé main. Typiquement, j'ai quelques dossiers à côté de cela où je travaille sur des fonctionnalités spécifiques ou des corrections de bugs ou autres, disons bug-escapingexceptions et feat-statefulchecking et patch-userFoo. Ceux-ci sont créés en utilisant hg clone.

Lorsque j'en ai fini avec une fonction ou une correction de bogue, je valide tout dans ce dossier et j'appuie sur la touche principale. Peut-être fusionner en main. (hg commit, hg push, hg merge). Ensuite, je supprime le dossier (attention en utilisant le statut hg et hg sortant que je ne jette pas quelque chose d'utile).

Je ne travaille presque jamais dans la partie principale, sauf juste avant une version, où je fais le nettoyage final (disons la documentation). Avant la sortie, je marque en main avec le numéro de version (tag hg v0.5.1).

Codeplex utilise svn comme sourcecontrol. Je ne l'utilise que pour stocker des versions, pour lesquelles j'utilise une copie de travail SVN vérifiée localement, à laquelle je copie le référentiel Mercurial en utilisant l'archive hg. Puis validez en utilisant svn. Primitive, mais cela fonctionne (l'utilisation de Mercurial en tant que super client SVN sur Windows n'est pas très facile à utiliser dans mon opnion)

Je n'ai pas encore fait de maintenance sur les versions précédentes, mais je le ferais En clonant le référentiel principal à partir de la révision de cette version (c'est facile, puisque je l'ai étiqueté), et travailler dans ce référentiel séparé. Rejoindre le tronc principal serait aussi simple que de pousser les changements à la fusion et à la fusion.

En résumé:

• Un dossier pour stocker tous vos dépôts de projet, avec le nom de votre projet
• Dans ce dossier un référentiel principal, et un dépôt transitoire par « unité de travail », avec un nom descriptif pour l'unité de travail.

C'est agréable parce que vos branches et ce sur quoi vous travaillez sont intuitivement visibles dans le système de fichiers.

Answer 2

Je ne sais pas pourquoi vous souhaiteriez avoir plusieurs référentiels, puisque vous sauvegardez déjà votre machine sur le lieu de stockage du référentiel.

Et peut-être que vous vous brancherez pour vous-même, si vous voulez explorer une fonctionnalité et ne pas vouloir brouiller dans votre branche de code principal.

Mais peut-être que vous allez extraire quelque chose sur un question que j'ai posé plus tôt.

Answer 3

Ce sont généralement les mêmes que pour un projet logiciel. Le simple fait d'avoir ou non le contrôle de version est au-delà de toute discussion;)

Habituellement, vous venez de valider lorsque votre fonctionnalité est prête. Puisque vous avez une sauvegarde, vous n'avez pas besoin de la valider tous les jours pour que votre travail soit stocké en toute sécurité.

Pour embranchement: dans mon projet solo je l'utilise principalement pour essayer des idées, par exemple. quand j'ai une autre solution pour le même problème. Pour cela, j'aime aussi la commande de dissimulation de Git.

Cependant, j'ai plusieurs dépôts. J'ai un hébergement avec accès shell que je pousse à. Donc, je peux synchroniser avec ce repo, peu importe où je travaille et quel que soit mon poste de travail (au travail: quand j'ai le temps de coder, à la maison et sur le bureau quand chez les parents).

Answer 4

Je pense que cela dépend si vous maintenez ou non une application existante et en ajoutant des fonctionnalités (ou en corrigeant de gros bogues) en même temps. De cette façon, vous pouvez corriger les bogues dans la branche principale tout en créant une nouvelle fonctionnalité dans sa propre branche. Je fais exactement cela avec mes applications, mais avec une version locale de CVS. En outre, si un nouveau développeur est ajouté à votre équipe, vous êtes prêt à partir. Je reconnais qu'il s'agit d'un problème distinct des sauvegardes.

Bonne chance,
Randy Stegbauer

Answer 5

Le SCM est une sorte de "smart" annuler l'extension de la mémoire tampon de votre éditeur. Vous pouvez remonter le temps, vous avez peut-être résolu un problème, mais vous l'avez supprimé, car il a été refactorisé, mais vous aurez besoin de la solution, etc. Mettez en place un diff visuel et il vous dira ce que vous avez changé depuis la dernière commettre ou dans les deux derniers jours, je revois constamment mon code et le change si je n'aime pas mon ancienne solution.Le branchement fonctionne sur les flux: lorsque vous commencez à aller dans une direction, mais que vous avez besoin de plus de réflexion et que vous souhaitez travailler sur autre chose, cela peut aider.

Prenez garde que les DVCS ne gèrent le référentiel comme une seule unité. Vous pouvez valider fichier par fichier (à l'aide de filtres), mais ils stockent les modifications dans l'ensemble du référentiel. Il confond les utilisateurs de cvs (svn) où les changements de fichiers individuels sont plus réguliers.

Answer 6

Une autre excellente raison d'avoir plusieurs clones (du moins si vous avez plus d'un ordinateur) est que vous voyez assez facilement si vous avez introduit des dépendances dans votre code. (Par exemple, votre code fonctionnera-t-il sur une autre machine, qui pourrait ne pas avoir tous les paquets de développement de votre poste de travail principal?)

Answer 7

De la façon dont votre question est formulée, je pense que vous pouvez avoir des malentendus liés à la terminologie de contrôle de version.

Vous devez disposer d'un seul référentiel pour chaque projet. Vous pouvez considérer un référentiel simplement comme un dossier sur le système de fichiers. Lorsque vous initialisez un référentiel Mercurial dans un dossier particulier, chaque fichier de ce dossier et de ses sous-dossiers peut être ajouté au référentiel pour être contrôlé par la version. Vous n'avez pas forcément besoin d'ajouter tout, mais n'importe lequel pourra être ajouté si vous le souhaitez.

Vous pouvez envoyer ce référentiel local vers un référentiel distant si vous le souhaitez, soit sous forme de sauvegarde, soit en tant que méthode de partage de votre code avec d'autres. Mais s'il s'agit simplement d'un projet personnel, cela ne sera probablement pas nécessaire, d'autant plus que vous avez déjà une solution de sauvegarde en place.

Les branches sont généralement utilisées pour conserver différentes "versions" du projet séparées. Comme certains l'ont mentionné, cela peut être utile en tant que développeur solo pour essayer une méthode de refactorisation du code, ou tester une approche différente d'un problème particulier. Si cela ne fonctionne pas, vous n'avez pas à vous soucier de savoir où retourner, vous venez de brûler la branche. Si cela fonctionne, vous fusionnez la branche dans le dépôt principal (le "tronc") et continuez.

Si vous arrivez au point où vous créez des "versions" du code, et que vous devez conserver les anciennes versions, vous devez également utiliser des branches. Par exemple, imaginez que vous libérez la version 1.0, et que certaines personnes commencent à l'utiliser. Pendant qu'ils l'utilisent, vous continuez en privé à travailler vers la prochaine version, peut-être 1.1, en ajoutant des fonctionnalités dans votre référentiel de jonctions. Maintenant, quelqu'un découvre un bogue dans le code 1.0 publié que vous devez corriger, mais vous ne pouvez pas le réparer dans le tronc et lui donner ce code, car il n'est pas dans un état à être libéré. C'est là que la branche 1.0 est utile. Vous pouvez corriger le bogue dans la branche 1.0 et fusionner la modification du bogue dans le tronc, de sorte que le bogue soit également corrigé. Ensuite, vous pouvez reconfigurer 1.0 avec la correction de bogues et le transmettre à vos utilisateurs, sans avoir à comprendre comment mettre le tronc dans un état qui pourrait être publié au public. En dehors de cela, il n'y a généralement pas beaucoup de travail sophistiqué impliqué dans l'utilisation de Mercurial solo. Faites un peu de travail, et quand vous finissez une fonction, engagez-la pour vous donner un "point de contrôle" auquel vous pourrez revenir dans le futur si nécessaire. Vous n'avez pas besoin de vous engager à chaque fois que vous sauvegardez ou quoi que ce soit de semblable, faites-le quand vous sentez que vous avez ajouté quelque chose de significatif. Cela vous donnera une bonne histoire du projet si vous avez besoin de regarder en arrière.

Pour plus d'informations, je suggère fortement de prendre le temps de lire ce livre: Distributed revision control with Mercurial. Vous n'avez pas besoin de lire les sujets avancés, mais lire au moins les chapitres 1-5 et 8 vous donnera une bonne introduction à Mercurial et au contrôle de version en général.

Answer 8

J'utilise un autre système de contrôle de version distribuée que Mercurial, mais je doute que cela compte pour cela.

Sur mes projets solo, j'utilise assez intensivement les branchements. J'ai typiquement une branche principale de développement ("tronc"), qui est censée avoir une version fonctionnante à tout moment. J'entends par là que les tests unitaires et autres tests automatisés passent, et que tout le code est testé par ces tests, à l'exception des petits bits que j'ai explicitement exclus de la couverture de test. Cela garantit que le coffre est toujours en bonne forme pour un développement ultérieur.

Chaque fois que je commence à travailler sur un changement, je crée une nouvelle branche à partir de la branche du tronc. Cela me donne la liberté de pirater librement. Je ne pourrais pas m'inquiéter des tests automatisés passant dans cette branche, par exemple. Puisqu'il s'agit d'une zone isolée, je peux m'engager aussi souvent que je le souhaite, et c'est ce que je fais: les microcrédits sont ma fonctionnalité préférée avec le contrôle de version distribuée. Lorsque le travail dans la branche est terminé, je le ramène au coffre.

L'avantage de ce style de travail est que s'il s'avère que les changements sur lesquels je travaille sont une mauvaise idée, je peux facilement reculer. En fait, il n'y a rien à abandonner, puisque les changements n'ont pas été fusionnés.

Parfois, je suis paresseux et ne crée pas une nouvelle branche pour quelque chose que je suis en train de développer. Invariablement, il s'avère que c'est une erreur, quand j'ai besoin de plus de temps que je pensais pour terminer le travail. Cela devient pire quand j'ai besoin de faire un autre changement, sans rapport avec le milieu de celui-ci. Lorsque je suis dans le style «tout en œuvre dans sa propre branche», le changement indépendant peut être effectué dans sa propre branche, fusionné en tronc, puis l'autre branche peut fusionner la modification du tronc, si nécessaire.

Answer 9

J'utilise quotidiennement Mercurial, voir here, je contribue également à l'un des rares services d'hébergement gratuit qui prend en charge Mercurial, ShareSource (je suis sur la page des crédits). J'utilise HG depuis Xen abandonné BitKeeper.

Je vous conseille, pour des projets personnels, d'éviter les succursales à tout prix. Le idea of what a branch is de Mercurial diffère beaucoup de ce que vous attendez. D'autres systèmes comme Git facilitent un peu les branchements (et les idées de savants fous). Cependant, je n'utilise Git que lorsque j'ai besoin de branches faciles et bon marché.

Ma journée typique avec hg:

(See where I left off) 
# hg status 

(See what I was doing with foo) 
# hg diff -r tip src/foo/foo.c 

(Finish one module, commit it) 
# hg commit src/foo/foo.c 

(Push changes) 
# hg push 

est aussi Merging assez simple, ainsi que tirer des révisions spécifiques des référentiels connexes. Mais, si votre solo, les chances sont si se présenter avec une fusion pour résoudre, vous avez probablement foiré en ne mettant pas à jour le repo à distance.

J'ai commencé quelques projets de passe-temps solo qui sont devenus très populaires un an après leur sortie, je suis content d'avoir utilisé HG. Sa syntaxe est proche de la subversion, elle est très intuitive et extrêmement portable.

Bien sûr, oui, j'utilise Git et SVN .. mais pas pour des projets personnels. Une note sur mon index repo (le lien posté), j'ai réécrit hgwebdir en PHP car je voulais modifier son look facilement et tirer du RSS de chaque repo.

En bref, pour un usage personnel, vous le trouverez TRÈS amical. Commits, tags, etc sont simples .. éviter les branches sauf si vous en avez vraiment besoin.

Ceci est un tutoriel que j'ai écrit il y a quelques temps décrivant comment utiliser Mercurial to manage a web site, vous pourriez trouver cela intéressant lors de la configuration de vos clés, hgrc, etc.

Answer 10

Je vous suggère de qui décrit les différentes façons dont vous pouvez mettre en œuvre le CCN et choisir la méthode qui correspond à la plupart du temps avec vos besoins

Answer 11

DVC comme Mercurial-- et Bazaar et Git-- ont fait beaucoup de choses à peu de frais disponibles de sorte qu'une armée de un peut bénéficier de capacités étendues.

1. Vous pouvez rapidement expérimenter avec code « jetable » si vous maintenez la discipline dans la tenue de travail branches à jour ou hors ligne principale et de synchroniser tous vos deltas de manière significative dans le DVC.

   Le code circule simplement sans souci, et en fait peut fournir une liberté mentale d'essayer plusieurs solutions avant de choisir la solution préférée.

2. Certaines personnes font des branches pour chaque fonction ils mettent en œuvre (en particulier dans git), quel que soit petit ou grand.En mercurial, cette approche de développement est bon marché, alors pourquoi ne pas utiliser la capacité ? Donc, cela pourrait signifier minuscules commits avec plus grands commits plusieurs fois par jour.

   a. Si vous avez adopté cette approche, vous voudrez peut-être pousser les modifications à une mise en pension hors hôte à la fin de la journée de travail afin de couvrir le temps entre travail effectué pour la journée et heure à laquelle la sauvegarde à WHS se produit.

   b. J'ai installé CopSSH sur mon WHS et cela fonctionne merveilleusement fournissant la fonctionnalité SSH/SFTP/SCP à la boîte de fenêtre dans ~ 5MB. Avant cela, j'étais en cours d'exécution Linux Ubuntu sur Virtual Server 2005 à fournir, entre autres services, similaire fonctionnalité. Vous pouvez pousser votre Mercurial à la boîte WHS sur ssh

Answer 12

Je l'ai utilisé CVS, Perforce, Subversion avant que mon système de contrôle personnel de version et est allé à Mercurial depuis il y a environ deux semaines :-) Au travail nous utilisons MS Team System ...

Pour moi, la nouveauté la plus notable est le transfert facile entre différentes machines. Au travail, j'ai des choses dans un repo mercurial (en utilisant hg en tant que Super-Client contre Team System). Je pousse/tire régulièrement tous les changements de/vers mon ordinateur portable pour avoir un historique complet sur les deux machines.

À la maison, je pousse aussi/tire le repo de l'ordinateur portable. En conséquence, je peux travailler où que je sois (bureau à domicile en utilisant un ordinateur costaud, sur la route en utilisant l'ordinateur portable ou au travail) et ne pas s'inquiéter si je vais perdre des changements. Ok, de temps en temps, j'ai besoin de fusionner deux changements, mais cela fait rarement mal ... hg le fait très bien à mon humble avis.

En outre, le "coût d'installation" avec mercurial est assez faible. Vous lisez un tutoriel, l'installez, dites "hg init" et continuez à travailler. Plus besoin de décider si quelque chose appartient à votre serveur SVN sacré, où le mettre et ainsi de suite. Le "frottement" de Mercurial est un peu inférieur à celui de SVN. J'utilise toujours Git ou Mercurial, même seul.

Answer 13

Je sépare les référentiels lorsque je veux rendre certains composants réutilisables disponibles pour d'autres projets. J'ai configuré à quand je commet, il pousse automatiquement aussi (j'ai fait avec Tortoise HG plugin), parce que parfois j'ai oublié de pousser, et quand déplacer géographiquement j'ai besoin de ce code, comprendre?

Alors, voici mes conseils.