Pour les projets personnels, Mercurial ou Git (ou d'autres DVCS) peuvent-ils offrir plus d'avantages que Subversion ?

Question

Quel est le système de contrôle du code source libre le plus approprié pour les projets et les documents personnels ?

Je pense utiliser Subversion (qui m'est familier).

Caractéristique du projet de maison :

1. Il est fort probable qu'une seule personne soit à l'origine des changements. (Il est possible qu'un jour (pas maintenant), je partage un projet avec mon ami qui se trouve dans une autre ville).

2. Je souhaite stocker d'autres documents (fichiers non liés à la programmation)

Est-ce que Mercurial ou GIT (système de contrôle de version distribué) peuvent me donner plus d'avantages que subversion dans les projets domestiques ?

Answer 1

Jetez un coup d'œil à la partie concernant le contrôle de version pour un développeur unique dans ma réponse à " Différence entre GIT et CVS "sur StackOverflow. Certains de ces problèmes s'appliquent également à Subversion par rapport à Git (ou à d'autres VCS distribués : Mercurial, Bazaar, ou moins connus : Monotone, Darcs), même si Subversion est une amélioration par rapport à CVS.

CLAUSE DE NON-RESPONSABILITÉ : J'utilise Git (je suis donc partial), et je ne connais Subversion que par la documentation (et d'autres ressources), sans l'avoir jamais utilisé moi-même. Il se peut donc que je me trompe sur les capacités de Subversion.

Vous trouverez ci-dessous une liste des différences entre Git et Subversion pour un développeur unique, sur une seule machine (compte unique) :

• Mise en place du référentiel. Git stocke le dépôt dans .git dans le répertoire principal de votre projet. Démarrer un nouveau projet à partir d'une arborescence de fichiers non versionnés est aussi simple que de faire "git init" dans un répertoire supérieur de votre projet (puis bien sûr "git add ." pour ajouter des fichiers, et par exemple "git commit -m 'Initial commit'" pour créer le premier commit).

  Dans Subversion (dans tout système de contrôle de version centralisé), vous devez créer un dépôt central (à moins que vous ne l'ayez fait plus tôt) en utilisant "svnadmin create" (en fait, vous ne devez le faire qu'une seule fois). Ensuite, vous devez importer des fichiers dans Subversion en utilisant "svn import" (ou "svn add")... Mais notez qu'une fois l'importation terminée, l'arbre original est no converti en une copie de travail. Pour commencer à travailler, vous devez toujours "svn checkout" une nouvelle copie de travail de l'arbre.

• Référentiel et métadonnées du référentiel. Git stocke à la fois le dépôt (c'est-à-dire les informations sur les révisions et les branches, etc.) et les métadonnées du dépôt (par exemple votre identité, la liste des fichiers ignorés, la branche en cours d'extraction) dans le répertoire .git dans le répertoire répertoire du haut de vos projets.

  Subversion stocke le référentiel dans une zone séparée que vous devez réserver à cet effet, et stocke les métadonnées du référentiel (par exemple, où se trouve le référentiel central, l'identité utilisée pour contacter le référentiel central, et je pense aussi des propriétés telles que svn:ignore ) sont stockés dans la base de données .svn dans le répertoire chaque répertoire de votre projet. (Notez que Subversion stocke une copie vierge de votre checkout, pour avoir un "svn status" et un "svn diff" rapides).

• Nommer les révisions / numéros de version. Subversion utilise des identifiants de révision globaux sous la forme d'un nombre unique spécifiant la révision (vous pouvez donc par exemple vous référer à r344, révision 344). Subversion supporte également quelques spécificateurs de révision symboliques : HEAD, BASE, COMITTED, PREV.

  Dans Git, chaque version d'un projet (chaque commit) a un nom unique donné par un identifiant SHA-1 de 40 caractères hexadécimaux ; en général, les 7 à 8 premiers caractères suffisent à identifier un commit (on ne peut pas utiliser un système de numérotation simple pour les versions dans un système de contrôle de version distribué -- cela nécessite une autorité de numérotation centrale). Mais Git propose également d'autres types de spécificateurs de révision, par exemple HEAD^ signifie le parent d'un commit en cours, master~5 signifie la révision 5 ancêtres en arrière (dans la ligne droite du premier parent) du top commit sur une branche 'master', v1.6.3-rc2 peut signifier une révision étiquetée v1.6.3-rc2 .

  Voir aussi Différents types de spécificateurs de révision article de blog par Elijah Newren.

• Branchements et fusions faciles. Dans Git, créer et fusionner des branches est très facile ; Git se souvient lui-même de toutes les informations nécessaires (la fusion d'une branche est donc aussi simple que "git merge branchname")... il le fallait, car le développement distribué conduit naturellement à de multiples branches. Git utilise une détection heuristique des renommages basée sur la similarité, ce qui lui permet de traiter, lors de la fusion, le cas où l'une des parties a renommé un fichier (et d'autres cas similaires liés au renommage). Cela signifie que vous pouvez utiliser branches thématiques workflow, c'est-à-dire développer une fonctionnalité distincte en plusieurs étapes dans une branche distincte.

  Les branches ont une implémentation inhabituelle dans Subversion ; elles sont gérées par un espacement de noms convention Une branche est une combinaison de révisions dans le référentiel global qui existent dans un certain espace de noms. La création d'une nouvelle branche se fait en copiant un ensemble de fichiers existants d'un espace de noms à un autre, enregistré comme une révision elle-même. Subversion a facilité la création de nouvelles branches... mais jusqu'à la version 1.5, il fallait utiliser des outils supplémentaires tels que les extensions SVK ou svnmerge pour pouvoir le faire. fusionner facilement. Subversion 1.5 introduit svn:mergeinfo mais même dans ce cas, la fusion est légèrement plus compliquée qu'avec Git ; il faut également utiliser des options supplémentaires pour afficher et utiliser les informations de suivi des fusions dans des outils tels que "svn log" et "svn blame". J'ai entendu dire qu'il ne fonctionne pas correctement dans des situations plus compliquées (fusion croisée), et qu'il ne peut pas gérer les renommages (il y a même un risque de corruption silencieuse dans ce cas). Voir aussi (par exemple) ce message sur la liste de diffusion git par Dmitry Potapov, expliquant le cas d'utilisation prévu pour la svn:mergeinfo et ses limites (actuelles).

• Tagging. Dans Git, les balises sont immuable Ils peuvent être assortis d'un commentaire et être signés à l'aide d'une signature PGP/GPG (et vérifiés). Ils sont créés à l'aide de "git tag". Vous pouvez vous référer à la révision en utilisant le nom de la balise.

  Dans Subversion, les balises utilisent l'espace de noms path_info-like convention en tant que branches (la convention recommandée est svnroot/project/tags/tagname ) et ne sont pas protégés contre les changements. Elles sont faites en utilisant "svn copy". Elles peuvent être associées à un commentaire [le commit créant une balise].

• Expansion des mots-clés. Git offre un ensemble de mots-clés très, très limité par rapport à Subversion (par défaut). Ceci est dû à deux faits : les modifications dans Git se font par dépôt et non par fichier, et Git évite de modifier les fichiers qui n'ont pas changé lorsqu'on passe à une autre branche ou qu'on revient à un autre point de l'historique. Si vous souhaitez intégrer le numéro de révision dans Git, vous devez le faire en utilisant votre système de construction, par exemple en suivant l'exemple de GIT-VERSION-GEN script dans les sources du noyau Linux et dans les sources de Git. Il existe également 'ident' gitattribute qui permet d'étendre le mot-clé "$Id$" à l'identifiant SHA-1 de contenu du fichier (non identifiant d'un commit).

  Git et Subversion ne développent les mots-clés que sur demande.

• Fichiers binaires. Git et Subversion traitent tous deux correctement les fichiers binaires. Git détecte les fichiers binaires en utilisant un algorithme similaire à celui utilisé par exemple par GNU diff, à moins qu'il ne soit surchargé par chemin à l'aide de gitattributes. Subversion le fait d'une manière légèrement différente, en détectant le type de fichier lors de l'ajout d'un fichier et en définissant le paramètre svn:mime-type que vous pouvez ensuite modifier. Git et Subversion peuvent tous deux faire conversion des caractères de fin de ligne à la demande ; Git a en outre core.safecrlf option de configuration qui avertit et prévenir les changements irréversibles (tous les CR à tous les CRLF sont réversibles, les CR et CRLF mixtes ne sont pas réversibles).

• Ignorer les dossiers. Git stocke les motifs ignorés à l'aide de l'arborescence .gitignore qui peut être placé sous contrôle de version et distribué ; il contient généralement des modèles pour les produits de construction et d'autres fichiers générés, et en .git/info/excludes qui contient généralement des motifs d'ignorance spécifiques à l'utilisateur ou au système, par exemple ignore pattersn pour les fichiers de sauvegarde de votre éditeur. Les motifs Git s'appliquent de manière récursive, à moins que le motif ne contienne un délimiteur de répertoire, c'est-à-dire la barre oblique '/', auquel cas il est ancré dans le répertoire .gitignore est ; dans le répertoire principal pour .git/info/excludes . (Il y a aussi core.excludesfile Cette variable peut exister dans les fichiers de configuration par utilisateur. ~/.gitconfig et pointer vers le fichier d'ignorances par utilisateur).

  Subversion utilise global-ignores option de configuration d'exécution (qui s'applique généralement à un ordinateur particulier ou à un utilisateur particulier d'un ordinateur), et " svn:ignore "sur les répertoires en version SVN. Cependant, contrairement à la propriété global-ignores (et dans l'option .gitignore ), les modèles trouvés dans les " svn:ignore "ne s'appliquent qu'au répertoire sur lequel cette propriété est définie, et non à aucun de ses sous-répertoires. De plus, Subversion ne reconnaît pas l'utilisation de la propriété ! préfixe du motif comme mécanisme d'exception.

• Modification des engagements. Dans les VCS distribués tels que Git, l'acte de publication est distinct de la création d'un commit, on peut modifier (éditer, réécrire) une partie non publiée de l'historique sans gêner les autres utilisateurs. En particulier, si vous remarquez une coquille (ou une autre erreur) dans le message de livraison, ou un bogue dans la livraison, vous pouvez simplement utiliser "git commit --amend". (Note : techniquement, il s'agit de recréer un commit, et non de modifier un commit existant ; le commit modifié a un identifiant différent). .

  Subversion ne permet de modifier le message de livraison qu'après coup, en changeant la propriété appropriée.

• Outils. D'une part, Git offre un ensemble de commandes plus riche. L'une des plus importantes est "git bisect" qui peut être utilisée pour trouver un commit (révision) qui a introduit un bogue ; si vos commits sont petits et autonomes, il devrait être assez facile de découvrir où se trouve le bogue.

  D'un autre côté, Subversion existe depuis plus longtemps, dispose d'un plus grand nombre d'outils tiers et d'un support de Subversion dans les outils que Git. Ou du moins plus mature. En particulier sous MS Windows.

---

Et il y a une autre question, qui pourrait s'avérer très importante par la suite :

• Dépôt de publication. Si (quand ?) à un moment donné, vous souhaitez partager votre dépôt, le transformer d'un projet individuel développé sur un seul ordinateur à la maison, en quelque chose d'autre contribuer, avec Git est aussi simple que de créer un dépôt vide sur le serveur ou sur l'un des sites d'hébergement git existants / sites d'hébergement de logiciels avec le support git (comme http://repo.or.cz , GitHub , Gitorious InDefero ; d'autres - également pour d'autres DVCS - sont listés dans cette réponse ), puis en poussant votre projet vers ce dépôt public.

  Je pense que c'est plus compliqué avec Subversion, si vous ne commencez pas sur un site d'hébergement de logiciels avec le support de Subversion (comme SourceForge) dès le début, à moins que vous ne vouliez pas préserver l'historique des révisions existantes. D'un autre côté, par exemple, Google Code suggère d'utiliser svnsync (qui fait partie de la distribution standard de Subversion), comme expliqué dans la section Google Products > Projet Hosting (Front de libération des données) article.

---

Jetez également un coup d'œil à http://whygitisbetterthanx.com/ site.

Answer 2

Un avantage évident : vous pouvez vous développer lorsque vous n'êtes pas sur le serveur. Par exemple, vous pouvez avoir un ordinateur portable avec son propre dépôt git local, et pousser vers votre serveur (ou github). Supposons que vous vous rendiez quelque part sans connexion internet... Avec Subversion, vous devriez vous contenter de n'effectuer aucun commit jusqu'à ce que vous soyez à nouveau connecté. Avec un DVCS, vous pouvez faire des commits localement (et revenir en arrière, faire des branches, etc.), puis pousser ces commits vers le serveur une fois que vous êtes rentré chez vous.

Answer 3

L'un des grands avantages de git et de mercurial dans le cadre d'un projet personnel est qu'un nouveau dépôt est facile à mettre en place. Dans git, il suffit de faire git init à la racine de votre arbre de code et vous avez un nouveau dépôt.

Vous pouvez alors ajouter, commiter, créer des branches, etc. directement. svn est plus coûteux à mettre en place car vous avez besoin d'un emplacement et d'une adresse url distincts pour le dépôt avant de pouvoir créer une copie de travail et commencer vos opérations VCS habituelles.

Le stockage de documents ne pose pas de problème avec git ou mercurial, mais avec git (je ne suis pas sûr pour hg), je déconseille de stocker de gros fichiers multimédias (à partir de 100M), car ils ont tendance à ne pas être très performants dans certaines opérations.

Answer 4

J'utilise git sur des projets personnels pour en quelque sorte "collaborer avec moi-même". J'ai des dépôts sur une machine linux sur mon réseau domestique qui est accessible via un tunnel depuis n'importe où. Je les clone ensuite sur mon ordinateur de bureau, mon ordinateur portable, peut-être sur une machine au travail, et je peux les voir ou travailler dessus partout où je vais. Je peux valider les modifications, obtenir la dernière version et avoir des sauvegardes à différents endroits. La facilité et la rapidité avec lesquelles git vous permet de changer de branche sont très appréciables. Vous avez trouvé un bug ? Passez à 'master', corrigez le, commit, push, puis revenez à ce que vous êtes en train de faire. Plus facile et plus rapide que cvs ou subversion.

De plus, j'utilise beaucoup git pour les petits répertoires qui ne sont même pas des projets. Le répertoire de configuration du serveur apache qui héberge mon site web est git'd, de même que le répertoire de configuration de tomcat pour le même site web.

Je l'utilise au travail pour tout, même si nous sommes en train de passer de CVS à Subversion. Je n'utilise pas git-cvs ou git-svn, j'utilise simplement git avec l'un ou l'autre produit, et je garde mes branches locales. C'est très pratique de pouvoir passer au dernier commit d'un autre développeur, de vérifier quelque chose, puis de revenir en arrière.

Et puis, bien sûr, il y a bisect, qui peut être d'une grande aide, que ce soit pour le travail ou pour les projets domestiques.

De plus, si au travail on utilise encore des cartes perforées, cvs ou subversion, l'utilisation de git à la maison est un excellent moyen de rester à la page et de découvrir par soi-même l'impact qu'il peut avoir.

Je ne m'enthousiasme pas pour les technologies à moins qu'elles n'apportent quelque chose de véritablement nouveau. C'est le cas de Git. J'en suis fan. Vous l'avez probablement déjà compris.

Answer 5

En dehors des détails sur les nombreuses et merveilleuses fonctionnalités de hg, git, darcs, bzr, et friends (pas de sarcasme ; je suis un grand fan), l'essentiel est là :

• Avec svn vous devez choisir entre le stockage de votre répertoire hors site et le stockage sur site. Sur place, cela signifie que si votre disque tombe en panne, votre projet est grillé. Hors site signifie que vous ne pouvez pas effectuer de validation depuis un avion ou d'autres situations de déconnexion, et lorsque la connectivité réseau est mauvaise, les validations peuvent être lentes.

• Avec tous VCS distribué, il est trivial pour créer un ou plusieurs "clones" de votre "repo". Vous pouvez s'engager des changements locaux à tout moment, rapidement, puis pousser ces modifications vers un dépôt distant lorsque la connectivité est disponible.

git, hg, et d'autres sont chargés de caractéristiques (et de défauts de caractéristiques) qui les rendent différents de svn et cvs. Mais il s'agit là des éléments essentiels.