Choix d'un soft de suivi de versions de sources - Page 1

Plop à tous,

Je cherche un VCS léger pour une utilisation pro. J'ai eu l'occasion de toucher à SVN depuis un peu plus d'un an, mais seulement en tant qu'utilisateur, pas administrateur. On m'a dit du bien de Mercurial, et aussi de Git qui semble être à la mode (mais j'ai aussi eu des échos que niveau ergonomie c'était pas encore ça, surtout sous Windows).

Voilà les caractéristiques que je recherche :

- pas trop casse-pieds à installer/administrer, ni trop gourmand en ressources (ça va tourner en local sur un PC qui sert aussi pour le dév, et qui n'est pas de la première jeunesse)

- intégration correcte dans Windows (quelque chose du style de TortoiseSVN serait très bien)

- sauvegardable facilement, idéalement de manière incrémentale

- fiable (bon j'imagine que tous les VCS sont censés l'être, mais j'ai entendu des histoires à faire peur à propos de Visual SourceSafe )

- pour le reste, je n'ai pas besoin de grand-chose : il est très probable que je sois le seul utilisateur, sur une seule machine. Disons qu'au pire ce sera quelques utilisateurs sur quelques machines, avec un nombre de commits et de conflits faible, sans besoin de tolérance de panne, backup à chaud ou autres raffinements.

Avez-vous des suggestions / retour d'expérience ?

SVN est sûrement le plus simple d'emploi (tant en tant qu'admin qu'utilisateur). Et ça passe en local (ton dépôt est un dossier local) qu'en mode externe (via internet, c'est super facile de mettre un apache). Accessoirement, il répond à tous tes critères.

Bon, il ne permet pas tout ce que permet git ou mercurial, mais il est tout de même bien plus simple d'emploi.

non a la trappe SVN! c'est de plus en plus lourds et buggé

git a pas mal d'avantages et surtout integre de base des outils graphiques (ok basé sur TCL/TK-aka) et aucun besoin de mettre un serveur en place vu que tout es en local.

Bien sur on peux mettre un serveur distant pour y "pousser" les commits, mais ce n'est pas indispensable.

Pour reprendre les points :

Zerosquare (./1) :
- pas trop casse-pieds à installer/administrer, ni trop gourmand en ressources (ça va tourner en local sur un PC qui sert aussi pour le dév, et qui n'est pas de la première jeunesse)

Zerosquare (./1) :
- intégration correcte dans Windows (quelque chose du style de TortoiseSVN serait très bien)

C'est peut etre la ou le bas blesse (comme qu'on dit) mais il existe un TortoiseGit. Attention TortoiseSVN masque beaucoup de choses de SVN et peux avoir des comportement un peu étrange quand on est habitué a la version CLI. D'ailleurs TSVN est malgrès tout pas mal buggé et peux bien faire ralentir l'explorateur de windows...

Zerosquare (./1) :
- sauvegardable facilement, idéalement de manière incrémentale

Git réponds tres bien a ça vu que tout le repository est en "local"

Zerosquare (./1) :
- fiable (bon j'imagine que tous les VCS sont censés l'être, mais j'ai entendu des histoires à faire peur à propos de Visual SourceSafe )

SVN comme GIT sont atomique par commit, et sont fiable (contrairement à CVS )

Zerosquare (./1) :
- pour le reste, je n'ai pas besoin de grand-chose : il est très probable que je sois le seul utilisateur, sur une seule machine. Disons qu'au pire ce sera quelques utilisateurs sur quelques machines, avec un nombre de commits et de conflits faible, sans besoin de tolérance de panne, backup à chaud ou autres raffinements.

Si tu es le seul utilisateur, GIT est, je pense, plus approprié. SVN, meme seul a besoin de creer un "serveur" (meme local et accessible via file://) la ou git permet de travailler directement.

Comme dit plus haut, git permet "simplement" via un "git gui" de regarder graphiquement le diff avec le commit précédent et ne commiter que les changement utile pour le commit suivant.
Il est recommandé avec git de faire des petits commits pour pouvoir utiliser la recherche par bijection de bugs introduits, et reste simple d'emploi.

Git est aussi plus "léger" que SVN quand il s'agit de repository a beaucoup de commit, il gère très bien les branches (mieux a mon sens que SVN)

J'ai fait du CVS, puis du SVN (que j'ai adoré a l'époque) puis avec réticence passé a GIT pour ne jamais en partir, c'est je pense ce qu'il y a de mieux. Il faut un petit apprentissage, qui est pas trop énorme si tu sais utiliser SVN, les deux sont assez proche sur la logique de fonctionnement, il y a juste quelques bricoles qui sont différentes, mais google donne dans 99.9999% des cas une réponse. Et pour le travail a plusieurs, je recommande aussi git pour la simple raison, c'est que chacun peux travailler sur X branches sans risque de gêner l'autre et ne pousser que les changements vraiment utiles, pas obligé de "pourrir" le serveur avec des version purement de tests qui au final finiront à la poubelle.


Sinon pour l'integration Windows, je pense qu'il est plus important une bonne intégration dans l'IDE que dans l'explorateur de fichier, tu y gagne plus en temps/praticité que via l'explorateur de fichier.

N'hésite pas si tu veux plus d'info sur git

Euh... de mémoire, non, SVN n'a pas besoin de créer de serveur (quand tu es en local évidemment)
d'ailleurs : http://blog.pagesd.info/post/2008/11/06/Utiliser-Subversion-en-local


Sinon, je pense que les points faibles et forts de git et svn sont bien résumés
reste mercurial qui est très proche de git.

Je confirme que SVN marche très bien sans serveur.
Je crois que git est plus simple a configurer que SVN pour que plusieurs utilisateurs d'un même ordi puissent l'utiliser.

Puisque tous les arguments ont déjà été donnés, je peux te raconter mon expérience.
J'utilise svn pour le boulot et autres. Il est simple à utiliser. J'ai jamais eu de bug. C'est une source sûre.
Je lisais que git et mercurial (hg) était bien plus fonctionnel que svn, surtout quand on écoute Torvalds.
J'ai donc essayé vite fait git. Rien compris.
J'essaye hg: les commandes sont plus compréhensibles, mais je suis loin d'être fluent, et j'ai perdu des données parce que j'ai lancé des commandes que je comprenais pas trop (il faut savoir qu'avec git et hg, tu peux modifier l'historique, donc supprimer des trucs committés, contrairement à svn).
Jusqu'au jour où j'ai compris que hg ou git ou bazaar ca s'utilise avec une interface graphique, pour visualiser ce que tu fais, au moins quand tu débutes.
J'ai trouvé une ihm géniale avec gitX, rien vu pour hg.
Maintenant que je comprend bien git, svn je trouve ca lent et inefficace lorsque tu veux faire autre chose que juste committer à la queue leu leu ou browser ton historique. Je peste maintenant contre mes collègues qui ont "peurs" de passer à git.

Rational ClearCase :
bien mais cher et trop lourd pour ton cas d'utilisation

TortoiseSVN :
2 possibilités : soit utiliser un serveur SVN et utiliser un client SVN (qui peut être TortoiseSVN), soit utiliser TortoiseSVN en local (pas besoin de serveur)
Après avoir utiliser SVN pour mes projets perso, je le trouve moins pratique que TortoiseHg (bon en même temps j'ai une vieille version peut-être que ça a évolué depuis.)

Git :
je l'ai un peut utilisé et que sous debian, donc je ne sais pas si TortoiseGit est correct ou non mais vu que Mercurial est équivalent...
Mercurial/TortoiseHg :
utilisé sous debian, RedHatEL et Windows, marche plutôt bien. Pas trouvé d'interface graphique digne de ce nom pour RedHat par contre.
Intégration correct dans windows.
Tu peux copier le repository (un répertoire .hg) n'importe où et ça marche.
Pas rencontré de problèmes pour l'instant avec.


Je conseillerais TortoiseHg.

Accessoirement, tu peux passer de SVN à Git (et peut-être à Hg). Je me demande si tu peux les utiliser simultanément.

je ne connais pas hg a vrai dire, mais oui tu peux checkouter un serveur SVN vers git (a coup de git svn clone)

!call Lionel Debroux
--- Call : Lionel Debroux appelé(e) sur ce topic ...

edit: j'ai oublié ça :

flanker (./4) :
Euh... de mémoire, non, SVN n'a pas besoin de créer de serveur (quand tu es en local évidemment)
d'ailleurs : http://blog.pagesd.info/post/2008/11/06/Utiliser-Subversion-en-local


Sinon, je pense que les points faibles et forts de git et svn sont bien résumés
reste mercurial qui est très proche de git.

Bien sur, quand je parlais de serveur, c'est qeu tu sauvegarde ailleurs que la ou sont tes sources, ça reste que le comportement est proche du client serveur, sauf qu'il n'y a pas de serveur au sens ou tu n'execute rien sur ta machien pour t'y conencter. En fait c'est le meme fonctionnement que le protocol svn+ssh, la seule chose requise c'est d'avoir un serveur SSH sur le serveur distant.

de ce que j'ai pu lire sur le net, ça n'a pas l'air de fonctionner correctement les migrations SVN => Git/Mercurial :/
(perte d'informations dans l'historique des fichiers, ce genre de chose :\)

Depuis 2007, après un court passage par SVK (surcouche à SVN pour permettre un peu d'utilisation en tant que SCM distribué), j'utilise quasi-exclusivement Git, au boulot comme en temps libre, en général au-dessus de SVN.
Git a "toujours" eu un excellent support de SVN, ce qui n'était pas le cas de Mercurial pendant longtemps.
Git et Mercurial sont plus difficiles à prendre en main que SVN, mais bien entendu, beaucoup plus puissants

Pour Git et Mercurial: le miroir local de tout l'historique des commits est pratique pour le travail en mode déconnecté / quand le serveur distant foire. Et pas de souci à se faire pour le stockage de milliers de révisions, Git et Mercurial utilisent une représentation très efficace des données. Du style, ~10K révisions d'un arbre SVN qui représente ~140K fichiers dans ~60K répertoires, pour ~400 MB dans le répertoire .git de la racine (et encore, il y a eu quelques fichiers binaires de quelques MB committés par erreur);

Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.
Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.

Quand on utilise Git au-dessus de SVN, il est rare d'avoir à repasser à SVN pour faire des manipulations. Une des principales raisons de ce faire que j'ai rencontrées est la suppression des répertoires vides suite à un renommage, Git ne versionnant pas les répertoires vides. En revanche, je n'ai pas subi de pertes d'historique, ni vu beaucoup de plaintes à ce sujet

gitk est un excellent visualiseur d'historique, et git gui permet de faire un certain nombre d'opérations pour committer, pousser, etc.; j'utilise aussi largement l'interface en ligne de commande (de toute façon, même si je voulais, difficile de faire autrement sur les machines headless sans serveur X ^^).

je sais pas si c'est possible via le CLI, mais le fait de pouvoir n'indexer que certains bout d'un fichier en vue d'un commit via git gui est irremplacable perso ^^

gitk est bien, mais par contre il y a pas mal d'outils equivalent qui existe en natif pour chaque OS

Lionel Debroux (./11) :
Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.

Dans TIGCC, j'ai fait ce genre de travail à plusieurs reprises avec rien de plus que patch et diff (et le CVS ne contient que le patch résultant).

Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.

Je ne vois pas le problème d'avouer qu'on a fait une erreur et de pousser un commit qui la corrige.

Godzil (./12) :
gitk est bien, mais par contre il y a pas mal d'outils equivalent qui existe en natif pour chaque OS

qgit = gitk en plus moderne.

Sinon, il y a git-cola qui est très pratique pour servir d'UI complet.

Merci à tous pour les réponses, je vais me renseigner davantage sur Git vu que ça a l'air de vous avoir convenu

Godzil: vrai, pouvoir sélectionner individuellement les changements à committer est une feature très utile de git gui.

Zerosquare: oui, je t'encourage à regarder Git
Tu connais déjà un CSCM (SVN), donc tu connais déjà un certain nombre de concepts, et tu verras les différences avec la philosophie DSCM... tu ne pourras vite plus t'en passer ^^
Avec Gitosis ou Gitolite (le plus récent des deux, je ne sais plus lequel c'est), il est très simple de mettre en place un serveur Git (par exemple à travers ssh).

Pour Git: très vite, je n'ai plus pu me passer du rebase et de la réécriture des commits. C'est grâce à ça que dans un précédent emploi, j'ai pu faire une série bisectable (tout compile et tous les tests passent, à chaque patch de la série) de plus de 20 patches, portant des features d'un fork d'une ancienne version du trunk (plus de 400 commits SVN en tout), vers une nouvelle version du trunk (qui avait eu de gros changements architecturaux par rapport à l'ancienne version) et qui continuait à évoluer pendant que je travaillais.

Dans TIGCC, j'ai fait ce genre de travail à plusieurs reprises avec rien de plus que patch et diff (et le CVS ne contient que le patch résultant).

Ce que tu as fait n'est pas comparable. Comme je l'ai écrit, j'ai fait une série incrémentale et cohérente de plus d'une vingtaine de patches, pas un seul gros patch. Entre autres, rebase ré-applique les patches (et propose la résolution des conflits), update automatiquement les lignes des diffs.
Dans mon emploi actuel également, j'utilise rebase quasi-quotidiennement, parce que c'est très efficace.

Dans mon emploi actuel, un de mes collègues et moi utilisons quasi-quotidiennement la réécriture des commits (distants, même si c'est déconseillé) pour synchroniser des versions de test entre machines. Ensuite, quand on a fait et testé plusieurs commits (y compris parfois des one-liners pour corriger des bugs idiots, du genre vérification de pointeur != nullptr - on code en effet en C++11), on pousse une version nettoyée vers le trunk SVN.

Je ne vois pas le problème d'avouer qu'on a fait une erreur et de pousser un commit qui la corrige.

Le but n'est, bien évidemment, pas de cacher les erreurs aux autres membres de l'équipe, dont le chef de projet: mon collègue peut voir mes erreurs, je peux voir ses erreurs, et les autres membres de l'équipe peuvent voir nos erreurs.
Non, il y a d'autres raisons excellentes en pratique - ces raisons qui font que Linux, Wine et plein d'autres projets ne poussent vers la branche principale que des séries faites aussi correctement que possible, plutôt que du code-and-fix non bisectable. La bisection est une feature très importante de Git et Mercurial, même si, pour les projets de taille limitée, elle n'est utile que sporadiquement. Sur Linux ou Wine, il y en a tous les jours.
De toute façon, sur nombre de projets ouverts qui utilisent l'organisation efficace du travail qu'est le commit de séries aussi bisectables que possibles, les séries de patches sont postées publiquement, sur des MLs ou sur des repositories Git, et restent accessibles longtemps... bref, pour cacher ses erreurs, on repassera

Tiens petit plus, un truc que j'essaye de mettre sur chaque machine que j'utilise avec git pour rendre la sortie console plus agréable, j'ajoute ça dans mon fichier .gitconfig:



[color]
ui = auto
[color "branch"]
current = yellow reverse
local = yellow
remote = green
[color "diff"]
meta = yellow bold
frag = magenta bold
old = red bold
new = green bold
[color "status"]
added = yellow
changed = green
untracked = cyan
[color]
ui = true
[color "diff"]
whitespace = red reverse
[core]
whitespace=fix,-indent-with-non-tab,trailing-space,cr-at-eol
[alias]
st = status
ci = commit
br = branch
co = checkout
df = diff
dc = diff --cached
lg = log -p
lol = log --graph --decorate --pretty=oneline --abbrev-commit
lola = log --graph --decorate --pretty=oneline --abbrev-commit --all
ls = ls-files

# Show files ignored by git:
ign = ls-files -o -i --exclude-standard


Ca fait plusieurs choses:
1 - ça met quelques couleurs histoire d'égayer un peu l'affichage CLI
2 - ça ajoute des alias dont des alias classique de SVN comme "st" (status) "co" (checkout) et des alias comme "lol" et "lola" qui affiche un vue "agreable" et concise des logs

Lionel Debroux (./15) :
Ce que tu as fait n'est pas comparable. Comme je l'ai écrit, j'ai fait une série incrémentale et cohérente de plus d'une vingtaine de patches, pas un seul gros patch. Entre autres, rebase ré-applique les patches (et propose la résolution des conflits), update automatiquement les lignes des diffs.

Qu'est-ce que tu crois que le "seul gros patch" contient? (Tu connais la réponse. )

Pour paraphraser un certain Cyril Hanouna "pas ce petit ton la pars ici"..

En plus tu va décolorer les bits a faire ça..

Kevin, Lionel > merci de ne pas régler vos comptes ici... (je préfère prévenir avant que ça dérape)

hibou (./6) :
J'ai trouvé une ihm géniale avec gitX, rien vu pour hg.

Je change peut être de sujet, mais qu'est-ce que vous avez vu de bien comme client pour git sous UNIX ou en cross-platform?
J'ai testé gitk, gitg, git-cola, mais je n'ai pas trouvé quelque chose de vraiment pratique à utiliser, je veux dire avec une interface simple et permettant de faire tout ce dont j'ai besoin...

Tu as besoin de quoi?

gitk par exemple ne fait que suivre les logs, gitg idem, git-cola ne fait qu'avoir une IHM digne d'un Unix de 1980..

Tu as testé git gui?

En effet, de quoi as-tu besoin ?
Gitk permet de suivre les branches et d'y apporter quelques manipulations; git gui permet de faire un certain nombre de manipulations (commits, pushes, pulls, GC du repo, etc.)
En revanche, si tu as besoin de faire un blame sur une partie de l'arborescence, mais seulement entre deux révisions, ou bien un simple `git svn rebase`, ça va être plus difficile de trouver une GUI.

Un argument important qu'on m'a opposé au pro a un moment où j'ai fait un essai de git, et j'y ai cédé parce que ça avait du sens:

svn numérote ses versions en incrémentant un nombre ce qui est pratique dans une relation clientèle, si N>M alors N est une version plus à jour que M, c'est clair, on peut y faire référence dans des mails, etc.
git n'utilise que des sha1 ce qui peut être considéré comme imbitable pour faire du tracking de version avec des non-développeurs.

Autre chose, svn permet de faire de la substitution de mots clés (comme $id$ pour intégrer automatiquement les révisions de fichiers dans des sources, par exemple) alors que git ne le fait pas.

Je connais et comprends les raisons techniques (pas moyen de gérer de numérotation monotone dans git a cause de la nature distribuée du système, alors que svn a un repository central) mais ça peut être un argument à prendre en compte, et c'est incontournable.

Sinon au niveau purement technique svn et git proposent la même chose quand on développe un projet tout seul, git ajoute le suivi local des révisions avec possibilité de "push" des historiques locaux et gestion facile des branches.

et je considère Hg comme un ovni basé sur la fierté de ses développeurs qui ont voulu faire autrement ce que les autres savent déja bien faire, donc plus tordu, et compatible avec rien, je veux même pas en entendre parler. Au mieux c'est équivalent à git, en moins bien.

Exemple pour les repository git distants on a github,repo.or.cz,et d'autres etc
mais http://www.hghub.org/ est under active development depuis combien de temps? etc etc c'est vraiment pas à conseiller à quelqu'un qui veut gagner du temps.

git n'utilise que des sha1 ce qui peut être considéré comme imbitable pour faire du tracking de version avec des non-développeurs.

C'est clairement moins trivial que les révisions SVN, mais il existe `git describe`, qui peut produire une sortie configurable, et plus proche d'un numéro de version à la SVN, prenant en compte les tags, branches, etc. La sortie de `git describe` peut être passée à `git show`, `git log`, `git whatchanged` et bien d'autres commandes.
Avec certains tags incrémentant de façon monotone (numéros de version croissants, une date triable YYYYMMDD, etc.), ça peut être utilisé pour comparer simplement les numéros de version.

et je considère Hg comme un ovni basé sur la fierté de ses développeurs qui ont voulu faire autrement ce que les autres savent déja bien faire

Mercurial et Git ont été faits exactement en même temps, pour répondre au même cahier des charges; ils ont été créés parce que les autres ne savaient justement pas bien faire ce dont Linus avait besoin (le meilleur SCM remplissait trois des quatre critères de Linus, mais il était très mauvais sur le quatrième, la performance).

La première version utilisable de Mercurial a été publiée légèrement avant la première version utilisable de Git, et il doit rester quelques trucs à Mercurial que Git n'a pas. En revanche, même si plusieurs gros hébergeurs proposent Mercurial, il est moins utilisé et moins interopérable que Git.

Lionel Debroux (./24) :
Mercurial et Git ont été faits exactement en même temps, pour répondre au même cahier des charges; ils ont été créés parce que les autres ne savaient justement pas bien faire ce dont Linus avait besoin (le meilleur SCM remplissait trois des quatre critères de Linus, mais il était très mauvais sur le quatrième, la performance).

D'ailleurs, git est d'une rapidité épatante. Dans svn 1.7 ils ont essayé d'améliorer les perfs en ne créant plus qu'un .svn, ben c'est encore très loin de perf de git. Et je ne parle pas évidement d'un parcours dans l'historique qui est incomparable entre les deux.

c'est la caractéristique de git

une des différences qui pourrait avoir un effet c'est que git ne traque pas des fichiers mais des contenus, le nom de fichier n'étant qu'une des metadata d'un blob. donc la gestion interne doit être assez différente entre les deux systèmes.

Godzil (./21) :
Tu as besoin de quoi?

Un client git qui me permette de voir l'avancée des branches et de faire les commits, push, et surtout de réaliser interactivement les merge.
Je cherche un client graphique simple, parce que je n'ai pas encore beaucoup l'hébitude de git.
Par exemple, j'ai remarqué que quand je fais un git pull, la branche courant n'est pas toujours mise à jour, et que j'ai besoin d'utiliser "git pull --rebase" pour actualiser les fichiers.
J'aimerais avoir un client graphique qui fasse ça automatiquement ou qui me permette de voir du premier coup d'oeil sur quelle branche je suis, si je suis à jour, etc.
Git gui c'est que sous windows non ? Perso il me faudrait un truc pour Ubuntu, si possible cross platform windows

y'a gitk et gutgui qui sont cross plateformes je crois

sous win c'est tortoisegit, sans doute pas parfait, mais pas trop dégueu quand même.

Non git gui est une aplpication "standard"' de git. Apres debian.buntu peuvent ne pas l'installer par défaut

Ah voui, t'as raison il est dans les dépôts