Meilleur contrôle de version pour un développeur solitaire

Question

Je suis un développeur solitaire pour le moment ; merci de partager vos expériences sur ce qu'est une bonne configuration de VC pour un développeur solitaire.

Mes contraintes sont les suivantes ;

• Je travaille sur plusieurs machines et j'ai besoin de les synchroniser.
• Je travaille parfois hors ligne

J'utilise actuellement Subversion (juste le client vers un serveur distant), et cela fonctionne bien. Je suis intéressé par Mercurial et git DVCS, mais aucun de leurs cas d'utilisation n'a de sens dans ma situation.

EDIT : J'ai migré mon développement actif vers Fossil. http://www.fossil-scm.org/ après l'avoir testé avec un client. J'aime beaucoup les fonctionnalités d'autosynchronisation de mes dépôts (réduisant les forks accidentels), le support de documentation (à la fois wiki et intégré/versionné) qui répond à mon besoin de documenter le code et le projet dans différents espaces, le gestionnaire d'incidents facile à configurer, le contrôle d'accès agréable, l'interface web personnalisable et la communauté serviable.

Answer 1

Chacun vous dira probablement que son DVCS préféré est le meilleur pour vous. Je vous dirais que Mercurial est le meilleur ! ;-)

Mais c'est de la merde . Vous avez certainement besoin d'un DVCS, mais essayez-les tous, ou du moins les plus utilisés, et faites votre choix vous-même. Choisir le DVCS pour lequel vous connaissez un gourou est également un choix judicieux, BTW. Je recommanderais d'essayer (ou de lire la documentation) au moins Mercurial, Git et Bazaar. SVK a peut-être l'avantage d'être conçu pour interagir avec SVN, mais la dernière fois que j'ai vérifié, ils avaient de gros problèmes de performance. Git dispose également d'un plugin d'interaction avec SVN, AFAIK.

Answer 2

Je me permets de vous suggérer un nouveau système de contrôle de version appelé fossil.

Il ne s'agit pas d'un projet "me too", il est écrit par le Dr. Richard Hipp, le même qui a créé SQLite. L'ensemble du référentiel est un fichier SQLite, il est donc très solide. Un wiki et un système de tickets sont intégrés. Vous pouvez avoir de nombreux utilisateurs avec des droits différents, vous pouvez par exemple donner à vos utilisateurs le droit d'émettre des tickets mais pas de voir le code source.

C'est assez simple, direct et cela fonctionne comme un système distribué, ce qui signifie que vous pouvez cloner et vérifier localement et à distance.

Plus d'informations sur http://www.fossil-scm.org/ et en y regardant de plus près, on s'aperçoit que l'ensemble du site est en fait fossile.

Une chose qui m'a vraiment impressionné avec fossil, c'est qu'il n'y a qu'un seul fichier, c'est tout. L'ensemble du programme fossil est plutôt petit, mais compte tenu de l'auteur, ce n'est pas vraiment une surprise.

Et comme votre référentiel est un fichier sqlite, il vous suffit de le copier pour disposer d'une sauvegarde.

Answer 3

Travailler hors ligne est tout à fait logique pour Git. Vous pouvez parcourir l'ensemble de votre historique, faire des commits, des merges, créer des branches, bref, faire tout ce qui est lié à votre dépôt hors ligne. De plus, vous pouvez mettre en place un dépôt central qui est le "master", c'est-à-dire que vous pousserez tous vos changements vers ce dépôt central. De cette façon, vous savez toujours où se trouve le code le plus récent, mais vous avez aussi l'avantage de pouvoir envoyer des modifications d'une machine à l'autre si vous en avez besoin.

J'ai récemment converti tous mes 80+ dépôts Subversion à Git, et je n'ai jamais regardé en arrière.

Answer 4

Bazar : Voir le cas d'utilisation en solo y Le bazar en 5 minutes .

En particulier pour l'utilisation hors ligne, un système de contrôle de version distribué est la voie à suivre.

Answer 5

Subversion fonctionne très bien (en particulier avec TortoiseSVN). Je ne pense pas qu'un VC distribué ait un avantage dans le cas d'un développeur unique.

Edit : je n'avais pas remarqué la partie "parfois je travaille hors ligne" lorsque j'ai répondu à l'origine. Dans ce cas, je suppose que vous devez pondérer la complexité supplémentaire d'un DVCS avec le fait qu'il vous donne un historique / des révisions hors ligne.