Cher journal,
voici mes réflexions sur les DSCM (Distributed Source Code Management), enfin
surtout Git et Mercurial, et tant qu'à faire,
j'aimerais bien avoir ton avis sur la question.
Je vais attaquer un projet pour lequel je vais utiliser un DSCM (non, je n'ai
vraiment pas envie d'utiliser Subversion), et je me suis donc
penché sur le sujet. D'un point de vue technique, les 2 gagnants sont Git et
Mercurial. Du moins, c'est l'impression que j'en ai, et elle est partagée avec
d'autres personnes avec qui j'en ai discuté. Je ne nie pas que les autres
(darcs, bazaar-ng, etc.) aient des qualités, mais ils m'intéressent moins que
Git et Mercurial.
Coté Mercurial, je vois comme avantage le fait que je l'ai déjà utilisé (ce qui
n'est pas le cas de Git) et que son utilisation est réputée plus simple. Ca ne
fait pas très lourd, surtout qu'on m'a dit que Git a fait de gros progrès sur
ce point avec les dernières versions.
De l'autre coté, j'ai l'impression que Git est en train de marquer des points
dans la guerre des DSCM, et de venir de plus en plus populaire. Depuis les
annonces de Mozilla et OpenSolaris,
je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial, alors
que je vois régulièrement des dépôts Git (utilisé pour du code, mais aussi pour
du packaging et de la doc). Du coté des hébergeurs, même topo : Tuxfamily a récemment annoncé le
support des dépôts Git, et je connais des hébergeurs spécialisés dans Git comme
GitHub, mais pour Mercurial, je ne pense pas
en avoir croisé.
Dans la communauté Ruby on Rails, cela me
semble encore plus frappant. La manière plus ou moins officielle de distribuer
des plugins est d'offrir un accès anonyme à un dépôt svn (en lecture seule,
l'accès). Mais plusieurs développeurs de plugins connus utilisent Git pour
développer les plugins, et synchronisent le svn juste pour les releases. Il
existe également des projets visant à utiliser les plugins quand on utilise Git
(comme Giston
ou Git-rails). Il me semble
que capistrano possède également un module pour Git. Et pour Mercurial ? je
n'ai rien vu, mais alors rien de rien.
Bref, j'ai l'impression que Git est en train d'écraser la concurrence, ce qui
veut dire que le développement de Git va surement avancer plus vite que celui
de Mercurial, qu'on trouvera de plus en plus d'outils pour Git, et surtout, que
des potentiels contributeurs auront plus de chances de connaitre Git que
Mercurial. Je pense que je vais choisir Git surtout pour ce dernier point, car
j'espère attirer des contributeurs dans les prochains mois et je ne voudrais
que le DSCM soit le moins possible un point de bloquage.
Et vous, chers lecteurs, vous-en pensez quoi ?
# Re:
Posté par IsNotGood . Évalué à 6.
Que tu devrais demander en premier à ceux qui vont participer à ton projet. Si tu es tout seul, un "DSCM" est sans intérêt.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 4.
[^] # Re: Re:
Posté par zebob . Évalué à 1.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 5.
Pour ma part, je préfère un bon Subversion. C'est simple, puissant, la doc est excellente, c'est intégré à Eclipse que j'utilise, ça marche partout, ça le fait.
Je connais mal git et mercurial. J'ai bien regardé le principe et c'est très intéressant. Mais très intéressant pour quelques projets hors-norme.
J'ai l'impression que tu veux un DSCM car c'est "hype", par curiosité. Et pourquoi pas. La curiosité, l'exitation d'utiliser un truc "hype" sont excellents pour la motivation et in fine pour le projet.
Mais si c'est la raison, et je la respecte lorsqu'elle est "avouée", tu n'as que faire de l'avis des autres. Fonce, prend ce qui te fait le plus kiffer. Si ton projet est bon, d'autres viendront. Que ça soit svn ou cvs ou git est accessoire (au moins au début). Lorsque le projet aura plus de contributeurs, tu pourras toujours changer de gestionnaire de version si le besoin s'en fait sentir.
> non, je n'ai vraiment pas envie d'utiliser Subversion
Et pourquoi ?
[^] # Re: Re:
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
La gestion par patch set correspond plus à ce qu'est le code source.
Pour combler ce manque, il exite les tags, mais il faut encore penser à les poser et souvent la granularité est trop grosse.
"La première sécurité est la liberté"
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 6.
Avec Clearcase tu n'as pas la notion de de transaction atomique et si tu commites un ensemble de fichier tu n'as aucune garantie que tu pourras commiter l'ensemble des fichiers en 1 seul bloc.
Avec SVN la notion de changeset existe et si un fichier entre en conflit au moment du commit la transaction est annulée jusqu'à ce que tu résolves les conflits.
La différence entre SVN la plupart des DVCS ets que lui historise des révisions de fichiers alors que les autres historise des diffs.
Dans la pratique, ceci n'a aucune conséquence, ca revient à faire la différence entre les piquets et les barrières.
Pour les tags avec SVN tu às tjs un numéro de révision qui correspond à un état de ton arborescence.
toutefois une bonne GCL ne peut se passer de marquer des configuration importantes et le "svn cp" sert aussi à initier des branches simplement
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 3.
Pour svn il faut parler de révision d'aborescence et non de fichier.
Si on commite un changeset on obtient une nouvelle révison de toute l'arborescence
Chacune des révision porte porte un identifiant unique et peut donc être retrouvée.
Ce qui n'exclut pas de tagger certaines révision, explicitement puisqu'on dispose de "cheap copy" .
Cheap Copies
Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. If you're a Unix user, this is the same concept as a hard-link. From there, the copy is said to be “lazy”. That is, if you commit a change to one file within the copied directory, then only that file changes—the rest of the files continue to exist as links to the original files in the original directory.
This is why you'll often hear Subversion users talk about “cheap copies”. It doesn't matter how large the directory is—it takes a very tiny, constant amount of time to make a copy of it. In fact, this feature is the basis of how commits work in Subversion: each revision is a “cheap copy” of the previous revision, with a few items lazily changed within. (To read more about this, visit Subversion's website and read about the “bubble up” method in Subversion's design documents.)
Of course, these internal mechanics of copying and sharing data are hidden from the user, who simply sees copies of trees. The main point here is that copies are cheap, both in time and space. Make branches as often as you want.
http://svnbook.red-bean.com/en/1.2/svn.branchmerge.using.htm(...)
[^] # Re: Re:
Posté par Guillaume Knispel . Évalué à 3.
En théorie les développeurs de SVN affirment que les temps des opérations sont à peu près proportionnels à la quantité de données transférée et que la taille totale du repo influe peu.
En pratique sur les gros projets au bout de quelques mois, quand le repository devient énorme, les temps de commit, update et j'en passe explosent (à plusieurs dizaines de secondes sur des transferts de quelques ko au max) et le bousin devient inutilisable.
Alors copy cheap ? pas cheap ? Ce qui me semble clair c'est que ya des algos d'une complexité trop importante qui ont du échapper à la vigilance de leur auteurs, en tout cas.
[^] # Re: Re:
Posté par MrLapinot (site web personnel) . Évalué à 2.
Ça ne peut pas être pire que la résolution des conflits dans darcs, en tout cas ;-)
Je médis mais c'est ce que j'utilise au quotidien et j'en suis très content (pour mon usage sur des projets de taille moyenne).
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: Re:
Posté par Guillaume Knispel . Évalué à 2.
Je n'ai aucune raison de sortir des bobards. Je préfère que tout le monde soit informé des limites des softs qu'ils pourraient être ammenés à utiliser histoire de faire le bon choix, plutôt que de cacher une limitation que j'ai constaté (pour faire quoi ? éviter de heurter ceux qui pense que le libre c'est tellement beau que les softs libres sont systématiquement purs et parfaits ?)
Et en même temps, je serais le premier à me réjouir si un jour cette limitation disparaît.
Ceci étant, sur un petit projet (ou un projet que vous pouvez découper dans pleins de repository) faites du SVN si vous n'avez pas d'autres raisons de vous en priver (process de dev, que sais-je), car avec peu de volume à mon avis le ralentissement mettra de nombreuses années avant de se faire ressentir.
Simplement sur un projet avec un gros volume de données, oubliez SVN en l'état actuel de ce soft.
[^] # Re: Re:
Posté par Éric (site web personnel) . Évalué à 4.
[^] # Re: Re:
Posté par patrick_g (site web personnel) . Évalué à 3.
Tu a regardé la vidéo de la conf de linus sur Git ? => http://www.youtube.com/watch?v=4XpnKHJAok8
Il est très véhément dans sa défense des DSCM, et ce pour tous les projets (pas seulement pour "quelques projets hors-norme".
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Les DVCS sont sans doute plus puissants que les VCS centralisés ,nul n'en doute. Maiss de leur puissance découle aussi une certaine complexité.
Ainsi on n'est obligé d'appréhender les concept de branches (pull/push)
de privilégier les merges qui est parfois une discipline hasardeuse tous les formats de fichiers ne s'y prêtent pas forcément. Avec un DVC le schéma de concurrence pessimiste est impossible/complexe puisque chacun travaille sur sa branche(/lock/modify/unlock)
Va demander à un AMO, ou un fonctionnel de merger des fichiers Word.
Va demander à de nombreux développeurs en forfait 1 mois de maitriser les outils de merge, les concepts des DVCS avant d'être opérationnels avec tout ce qu'il ont d'autres à assimiler dans leur nouveau contexte alors qu'on leur demande juste de sauvegarder leur travail dans un espace securisé.
Les DVCS sont donc des outils de niche qui selon moi se limitent à des projets libres purement communautaires ou interviennent des développeurs chevronnés et/ou passionnés.
Ce type d'outil n'est pas adapté au monde de l'entreprise.
Or de plus en plus les entreprises participent aussi à l'essor du libre
(contribution occasionnelles, passage de produit en open source, modèle en double licence, ...)
Dans ce cas les DVCS aussi puissants soient-ils (travail deconnecté , pas d'identifcation) sont un frein.
Reste un argument:
les DVCS qui supportent vraiment les 2 modes d'accès centralisé et distribué, mais à quoi bon alors faire compliqué lorsqu'on peut faire simple. Au cas où on en aurait besoin ?
Ceux qui ont travaillé avec ClearCase multisite (mode distribué de Clearcase) me comprendront. Le multisite en tant que palliatif des piètres performances entre 2 sites distants (proxy) n'a plus lieu d'être avec SVN qui est très performant même à distance.
Alors pourquoi se compliquer la vie avec 1 branche par site quand on travaille sur les même sources alors qu'on peut tous travailler dans la même.
Et ne parlons pas de l'aspect "user centric" lié à l'usage d'un DVCS vs "repository centric". Le premier impose un modèle d'organisation.
Les dictateurs en entreprises sont rarement éclairés et bienveillants .
Ceci explique sans doute cela:
http://blogs.open.collab.net/svn/2008/02/subversion-stil.htm(...)
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
La question est surtout :
Pour quel gain ?
Pour la majorité des projets, ça n'apporte rien. D'un côté c'est pénalisant et souvent ça n'apporte rien.
Pour ma part, et je suis développeur, je n'ai jamais senti le besoin d'un DVCS. Ceci dit, je n'en nie pas les atouts, je n'en conteste pas le principe. Le développement de Linux (le noyau) est une "forêt d'arbre avec plein de branches". Tous les projets n'ont pas cette complexité. Fort heureusement.
C'est un peu comme connaitre l'assembleur. Pour certain projet c'est super. Mais que ça soit super (voire indispensable) pour certains projets, n'implique pas que c'est important pour tous les projets. Imposer l'assembleur ou un DVCS comme ticket d'entré à un projet sans une bonne justification est contre productif.
En passant, un hommage à Subversion.
Subversion est un excellent gestionnaire de version. Pas révolutionnaire, c'est clair. Mais excellent. Incontestablement l'un des meilleurs. Je suis navré de voir comme il est si souvent "boudé" alors que les développeurs de subversion ont fait un excellent travail, avec une remarquable compréhension du besoin, le tout avec un souci de la qualité (fiabilité, compatibilité, documentation, internationnalisation, etc) que j'aimerai voir dans beaucoup de projet.
Chapeau bas.
La superbe doc de Subversion :
http://svnbook.red-bean.com/en/1.4/svn-book.pdf
Pour ceux qui ne connaissent pas les gestionnaires de version, c'est aussi une excellente lecture.
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 1.
Tu as prouvé ta méconnaissance de git dans ce thread, n'en rajoute pas. svn est correct. git est juste mieux, plus rapide pour les opérations courantes, possibilité de tout faire hors-ligne et de push plus tard, et à des trucs supers avancés comme bissect.
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 3.
Ensuite, c'est juste un débat sur distribué/centralisé, plus que sur les outils eux même (git ou subversion). Dans certains cas, le distribué n'apporte rien, par exemple :
- un petit projet qui débute dans son coin, avec peu de codeurs
- un projet internet à une entreprise qui a besoin d'avoir un référentiel centralisé
- un projet où les développeurs sont sédentaires et ne passent pas leur temps à coder pas dans un avion
L'aspect distribué apporte des avantages nombreux, mais aussi une certaine complexité, d'après ce qu'on en dit. La question sur un projet est donc de savoir si l'aspect distribué fait partie des besoins, ou n'a que peu de chances d'être utilisé.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 5.
Enfin la dernière fois que j'ai essayé de faire un merge avec subversion, ça m'a pris plus d'une heure. A la fin j'ai décidé d'utiliser bazaar-ng avec le plugin svn pour faire mon merge, c'était beaucoup plus simple.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
C'est beau de le reconnaitre.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 4.
Mieux pour quoi ?
Pour les trucs de ouf comme Linux où il y a 200 branches en parallèle et aucune synchronisé ? Ou tout le monde s'échange des patchs pour faire des testes ? Ou 50 branches différente veulent tester le patch bidule ?
Oui dans ce cas, git est mieux. Indiscutable mieux.
Désolé d'être modeste, mais je ne bosse pas sur ce type de projet. Je n'ai pas le niveau.
Et désolé d'être cruel, mais il n'y a qu'une toute petite minorité de développeur qui peuvent s'aventurer dans Linux (je parle du coeur, je ne parle pas d'écrire seulement un driver (ce qui est très respectable)).
Et fait, je ne suis pas modeste, j'ai la prétention d'être un bon développeur. Pas une pointeur pour bosser sur le noyau Linux, mais un bon développeur. Un mec qu'on ne berne pas si je peux me permettre.
Il y en a qui jongle avec les diff et merge à longueur de journée. Je les admire.
Tu fais parti de cette catégorie ?
Bravo pour toi.
Mais tout le monde n'est pas dans cette catégorie.
Il ne faut pas laisser croire qu'un bon programmeur, qui fait son taff correctement, qui est une bonne contribution, un développeur sur qui tu peux faire confiance et pas un développeur qui te vomie un patch en disant que pour les bugs il regardera ça plus tard, a besoin d'être dans cette catégorie.
Que s'il se satisfait de subversion alors ce n'est qu'un minable. C'est faux.
Et les autres ne devrait pas croire d'utiliser git est une preuve d'intelligence ou la marque d'un bon développeur. Git n'est qu'un outil parmis d'autre. Ça doit s'apprendre 3 ou 4 jours.
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 2.
Les projets sur lesquels j'utilise git sont des petits projets. Le gros projet sur lequel je bosse utilise hélàs un outil largement depassé (CVS) et j'espère qu'on switchera vite.
git permet je pense d'aller plus vite (pour le développement, je ne parle des autres cas cités précédemment) au cout d'une certaine discipline humaine.
Quand à savoir qui a la plus grosse, je te la laisse :D
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Il est spécifiquement conçu pour être optimal avec Linux
Hg est moins rapide mais plus portable
Bref le choix de git dépend du contexte du projet et ce n'est certainement pas un outil universel.
[^] # Re: Re:
Posté par alice . Évalué à 1.
C'est particulièrement énervant quand on veut faire une modification importante, mais pas suffisante pour créer une branche.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Bof...
Les copies sous Subversion ne sont pas cher. Donc l'admin te fait une branche sur le server et l'affaire est pliée. Les bons admin laissent tous les utilisateurs faire des copies dans, par exemple, branches/devel. Aucun risque de perdre des données, c'est versionné :-)
Une fois le boulot terminer, il suffit d'un "svn rm ma_branche". Et rien est perdu évidemment. Ce n'est simplement plus visible dans la version HEAD.
Et comme ça tu profites des sauvegardes du serveur, les autres peuvent piocher dans ton boulot ou y participer en un rien de temps, etc...
Plein d'avantages à ne pas négliger.
Mais si t'aime bosser en solo...
> C'est particulièrement énervant quand on veut faire une modification importante, mais pas suffisante pour créer une branche.
Les branches sous subversion ne coûte rien.
[^] # Re: Re:
Posté par alice . Évalué à 2.
[^] # Re: Re:
Posté par Bruno (site web personnel) . Évalué à 3.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
La conséquence est que les changesets doivent être disjoints. Si 2 changements ou correction de bug concernent le même fichier on ne pourra pas distinguer à quel changement s'applique les différentes modifs sur ce même fichier et il faudra impérativement commiter les 2 changelist qui se recouvrent.
[^] # Re: Re:
Posté par Bruno Michel (site web personnel) . Évalué à 6.
Quant aux avantages de svn, j'ai du mal à les voir.
La simplicité ? je ne pense pas que svn soit plus simple que git ou mercurial.
Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?
Doc excellente ? Oui.
Intégration à eclipse ? Oui, mais Git a aussi un plugin, et je n'utilise pas eclipse.
Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).
Ca le fait ? Oui, mais un DSCM, ca le fait aussi ;-)
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
Pourquoi pas.
> Puissant ? heu, tu pourrais détailler ce que svn a de plus puissant qu'un DSCM ?
J'en sais rien. Mais svn reste puissant. copie gratuite, une révision est un snapshot, accès concurrent au serveur sans problème, les conflits sont gérés, les attributs (type mime, information sur eof (native, crlf, etc), bit exécutable), les liens symboliques, synchronisation de dépôt, backup à chaud, etc.
> Ca marche partout ? Non, ca ne marche que quand on est connecté au dépôt (donc pas dans le train).
Ouais, ouais, ouais....
Si on sait faire un patch et qu'on n'est pas un manchot ça je gère ce type de situation (qui reste exceptionnelle).
Effectivement, si tu bousses tous les jours dans le train, il vaut mieux un DVCS.
[^] # Re: Re:
Posté par Hank Lords . Évalué à 7.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
[^] # Re: Re:
Posté par Boa Treize (site web personnel) . Évalué à 5.
Un DSCM tel que Git t'apporte :
- facilité à faire des branches
- bissection
- puissante visualisation d'historique
- facilité à travailler sur plusieurs machines
- performance
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
Avec subversion il suffit d'un "svn cp" (tu as toujours la traçabilité de l'historique).
> - bissection
???
C'est un merge ?
Facile avec subversion.
> - puissante visualisation d'historique
Pareil.
> - facilité à travailler sur plusieurs machines
???
Je ne vois pas en quoi.
> - performance
Si t'es tout seul à l'utiliser... (c'est l'hypothèse de Hank Lords).
[^] # Re: Re:
Posté par Sébastien Le Ray . Évalué à 2.
> - bissection
???
C'est un merge ?
Facile avec subversion.
La bissection n'a rien à voir avec le merge et il n'y a, à ma connaissance, pas d'équivalent, simple, sous Subversion.
En gros tu dis "rev 1234 je suis sûr que ça marchait, rev1300 ça marche plus" et ça va te permettre de parcourir simplement les différents états de ton code entre les deux révisions jusqu'à ce que ça fonctionne...
[^] # Re: Re:
Posté par IsNotGood . Évalué à 2.
"svn switch" ?
Ce n'est pas compliqué, il suffit d'ajouter "-r [révision]" et voila.
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 5.
Avec bissect, tu definis deux tags good et bad (l'un tu es sur que ca marchait, l'autre tu es sur que ca marche). Il prend un changeset au milieu, revient à cette état, tu test ton bug et tu marque cet etat good ou bad. Et ensuite, on recoupe, jusqu'a trouvé le commit qui introduit le bug.
C'est faisable avec un SCM classique, à la main, mais c'est très chiant.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 4.
Bref encore une commande occasionnelle qui n'a pas été implémentée dans SVN et on en fait tout un foin.
On finira bien par la retrouver dans un plugin si elle est si importante.
Inutile de polluer l'outil avec une commande de plus.
Quand on regarde le man de git on prend déjà peur.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
Un bloque note...
> C'est faisable avec un SCM classique, à la main, mais c'est très chiant.
$ svn switch -r 100 [url]
$ # tu testes, ça marche.
$ svn -r 101 [url]
$ # tu testes, ça ne marche pas. Tu notes sur un postit que la version (ou changeset si tu préfères) 101 a introduit une régression
$ svn update # tu passes à la version HEAD
$ # Tu récupères (ou visualise seulement) le diff qui a introduit le bug (tu peux le faire n'importe quand).
$ svn diff -c 101 > patch_qui_sucks # le '101' que tu as écrit sur le postit
$ # tu peux évidement regarder le log du "changeset" 101
$ svn log -r 101
# blabla
Et voila.
Après tu peux faire des trucs plus exotique comme :
$ svn switch [url]/branche_stable
$ svn merge -c 101 [url]/trunk
$ # ça marche sur la version stable. Donc le "changeset" 101 n'est pas le seul en cause dans le problème.
$ # un autre bug a probablement aussi été intégré à la de développement dans autre version que la version 101.
$
$ # tu peux forcer la version d'un sous-répertoire
$ svn update -r 90 lib
$ # le répertoire lib est à la version 90 et le reste à la version 95 par exemple
$ svn merge -c 101
$ # Damned, ça marche ! Le problème est une combinaison d'un bug dans /lib et du "changeset" 101
C'est si compliqué que ça ?
Bien des choses sont possibles avec svn si on le connait. Et fort heureusement il n'est pas compliqué tout en étant puissant.
Si git est plus simple, j'aimerai bien un démontration comme je viens de le faire avec svn.
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 2.
Pour la documentation, je te laisse le soin de faire un man git-bisect, tout est très clairement documenté (ici par exemple http://linux.die.net/man/1/git-bisect)
git contrairement à svn est documenté par des pages man ...
L'avantage de svn ici c'est que les changesets sont consécutifs, donc la bissection est plus aisée.
Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl. On a rarement l'occassion de voir des outils plus Unix, et plus faciles à customiser.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 1.
Déjà ce qui fait peur, c'est qu'il faille passer une url. On peut pas le faire sur place, en étant deconnecté ?
Ben par définition avec un outil centralisé tu stockes pas tout un repository en local donc oui faut aller récupérer sur le serveur ce qu'il te faut et juste ce qu'il te faut au moment ou tu en as besoin.
Avec ton système si tu n'as cloné que récemment le projet, tu vas déjà "explicitement" recupérer la branche de ta révision ou ta révision (qui va remonter la branche associée)dans ton archive.
Avec svn le switch ne transfère que le strict nécessaire
Bref rien de choquant.
Le seul avantage que je vois à un DVCS est l'effet proxy.
A force tu conserves en local toute les révisions que tu as récupérées. peut-être avec l'avantage du cache en moins. Il ne se vide pas automatiquement lorsqu'il devient trop volumineux.
Espérons que les DVCS sont concus pour mutualiser le stockage des archives en local parce qu'avec 50 clones de tout un projet ca va vite saturer la place.
En outre il n'est pas inconcevable (si ce n'est pas déjà le cas) de disposer de cache avec SVN si le besoin s'en fait ressentir. Perforce le fait bien et il est centralisé
git contrairement à svn est documenté par des pages man ...
Ben oui encore une preuve que cet outil est concu d'abord et avant tout pour des linuxiens pur et dur et pas prévu être multiplatforme.
Bien des choses sont possibles avec git si on le connait. Et fort heuresement, il n'est pas compliqué tout en étant puissant. La moitié des commandes sont en shell ou en perl.
Même remarque
Un projet multiplateforme qui a vraiment besoin de l'aspect distribué a donc tout intérêt a utiliser Hg.
Le posteur du journal nous a confié qu'il bossait sur RoR donc ca devrait l'aider à prendre sa décision puisque ruby et RoR tout comme python répondent au critères de portabilité et peuvent donc concerner des devs d'horizons différents.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
$ svn info | grep ^URL
Et tu l'as l'url.
> On peut pas le faire sur place, en étant deconnecté ?
Vas pas sur dlfp, on ne peut pas poster des commentaires en batch.
zul exige un dlfp décentralisé !
> http://linux.die.net/man/1/git-bisect
Le "git bisect run my_script" est effectivement cool.
> git contrairement à svn est documenté par des pages man ...
la command svn est très bien documentée.
Exemple :
$ svn help update
update (up): Actualise la copie de travail par rapport au dépôt.
usage : update [CHEMIN...]
La copie de travail est actualisée à la révision HEAD ou à la révision
précisée par l'option -r.
L'opération effectuée sur chaque objet est donnée par un caractère :
A ajouté
D supprimé
U modifié
C en conflit
G fusionné
La première colonne concerne l'objet, la seconde ses propriétés.
Un 'B' en troisième colonne indique qu'un verrou a été volé ou cassé.
Options valides:
-r [--revision] ARG : ARG (peut aussi être une étendue ARG1:ARG2)
L'argument d'une révision peut être :
NUMÉRO numéro de la révision
'{' DATE '}' révision disponible à cette date
'HEAD( dernière révision du dépôt
'BASE' rév. de base de la copie de travail
'COMMITTED' dernière propagation à ou avant BASE
'PREV' révision juste avant COMMITTED
-N [--non-recursive] : opère sur un seul répertoire
-q [--quiet] : essaie de se taire
--diff3-cmd ARG : utilise ARG comme commande de fusion
--username ARG : précise le nom d'utilisateur ARG
--password ARG : précise le mot de passe ARG
--no-auth-cache : ne conserve pas les éléments d'authentification
--non-interactive : pas de demande interactive
--config-dir ARG : fichiers de configuration dans ce répertoire
--ignore-externals : ignore les références externes
Ça vaut un man.
[^] # Re: Re:
Posté par z a . Évalué à 3.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
> c'est pas un truc en vrac
Ben justement, ce n'est pas un truc en vrac. Si on ne connait pas un outil, utiliser les pages man est rarement la voix la plus facile. Si on connait et que les pages man concentrent toute la doc, ce n'est pas pratique.
Si tu veux l'équivalent des pages man :
http://svnbook.red-bean.com/en/1.4/svn.ref.html
Et notes bien ça :
http://svnbook.red-bean.com/en/1.4/svn.ref.svn.html#svn.ref.(...)
Une option a toujours la même signification quelque soit la sous-commande. Ce n'est pas du "en vrac".
Ça rend les commandes et leurs options trivials à assimiler et donc l'aide en ligne ("svn help") est largement suffisante. Évidemment il faut avoir compris le fonctionnement global de subversion (c'est comme ça pour tous les programmes).
> un man ça peut se lire dans un pager
Git c'est 139 pages man, plus de 20 000 lignes. À 50 lignes par page, ça fait "seulement" 400 pages. Je te souhait bien du plaisir pour assimiler git avec ça.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
On va te refaire un script shell au ptit poil qui traite ton cas et on vas le rajouter dans le "man".
On lui trouveras un joli petit nom qui en jette après "bisection" on l'appellera "quadrisec....
Et après on pourra troller comme des oufs en disant que svn sait pas le faire autrement qu'à la mano. Dans les choux SVN
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Dans de nombreux projets, on n'héberge pas que des fichiers sources mais aussi des fichiers qui ne peuvent pas être mergé car on ne dispose pas d'outils appropriés(charte graphique , images, fichiers UML, XML, ...). Embêtant pour celui qui devra tout refaire ses modifs à la mano pour ne pas écraser celle du premier qui a commité.
Avec SVN tu places le fichier en lecture seule et tu obliges à locker le fichier avant toute modification.
Avec un DVCS pas facile de locker ledit fichier dans toutes les branches de la création surtout lorsqu'on a pas accès aux repository des autres.
Seule solution déporter la gestion de la concurrence (bug tracker, serveur web) à un outil tiers pour "centraliser" en comptant sur la rigueur et l'infaillibilité des membres du projet.
Mais on y arrive, tout comme à résoudre ton cas.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
Et pour le merge, tu fais comment avec SVN ?
> > - puissante visualisation d'historique
>
> Pareil.
Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.
Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.
> > - performance
>
> Si t'es tout seul à l'utiliser... (c'est l'hypothèse de Hank Lords).
Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.
Bon, je te propose un truc : si tu veux faire un comparatif Git Vs SVN, utilise un peu les deux. Là, tu parles de manière affirmative d'un truc que tu connais à peine, c'est dommage.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Et pour le merge, tu fais comment avec SVN ?
Non, t'as jamais vu gitk ou n'importe quel équivalent pour dire ça. Premier truc : avec SVN, tu ne vois que l'historique des branches, jamais l'historique des merge. Il manque un truc capital pour comprendre l'historique. SVN voit un arbre, Git voit un DAG.
Après, essayes de voir l'historique de deux fichiers ensembles avec SVN.
La mémoire des merge vient avec la nouvelle version de SVN (encore en bêta mais parfaitement utilisable.)
http://blogs.open.collab.net/svn/2007/05/the_subversion__1.h(...)
Cette fonctionnalité attendue le hisse la hauteur des meilleurs DVCS sur ce point et il n'est guère étonnant que les DVCS étaient plus avancés sur ce point car on ne peut pas travailler sans les branches avec eux, même sur de petits projets
Gageons qu'avec cette avancée des plugins du type de celui que tu cite ne tarderons pas à venir.
Mais si tu penses que tout est pour le mieux dans le monde merveilleux des merges pour les DVCS, je t'invite à te rendre sur ce wiki très intéressant qui relate tous les approches pour merger au mieux dans les DVCS et visiblement la "silver bullet" n'existe pas.
http://revctrl.org/CategoryMergeAlgorithm
Le mieux est donc encore de s'isoler le moins possible en intégrant au plus tôt les modifs pour ne pas tomber dans des cas tordus. Ce à quoi n'incite pas les DVCS
Ah et autre chose Clearcase dispose de la mémoire de merge depuis longtemps et dans sa version UCM te permet de consulter l'historique des merge au niveau de l'arborescence (projet en entier) et du fichier.
Bref ce n'est pas une spécificité des DVCS
Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.
Et sous windows aussi ?
Un truc qui a été nativement conçu pour ne cibler qu'une seule plateforme, j'ai du mal à le croire
Vraiment, les seuls avantages d'un DVCS sont les suivants:
- Pas besoin d'administration (ouvrir un accès) ni d'en passer par un diff /patch pour un contributeur occasionnel (un pull de sa branche et c'est parti). Ca limite le scope au monde du libre. Le monde de l'entreprise a de toute façon besoin de contrôler les accès.
- Possibilité d'historiser plusieurs versions en local. Avec SVN on peut de toute façon travailler en déconnecté et à peu de frais, on peut monter un petit repository en local et scripter des commits successifs dans une sous-branche sur le serveur. En général il n'est pas bon de travailler isolé trop longtemps de toute façon car les merges sont plus délicats.
Et si vraiment ca te manque tant que ça tu as svk
http://svk.elixus.org/view/HomePage
En regard de la complexité dans la gestion des branches ca me parait mince comme avantages
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Avec la commande "svn merge".
Surpris ?
> jamais l'historique des merge.
Juste.
> Lapin compris. Git est incroyablement plus rapide que SVN, que tu l'utilise tout seul ou pas, c'est un fait.
Super. Si tu fais 2000 commit dans la journée c'est définitivement un plus. Si tu n'en fait que 10 en moyenne (ce qui est une belle valeur lorsque tes commit sont fait intelligement), ben t'as gagné au mieux 1 minute.
Mais c'est super sinon.
[^] # Re: Re:
Posté par carlo . Évalué à 3.
Tu peux être dans ton dépôt local, faire des commits, des clones et tout ça sans besoin d'accès à ton dépôt central (si tu en as un).
Bon, il y a plein d'avantages à utiliser un DSCM et je ne les connais pas tous, ni ne les évalue bien tous (je débute) mais tu peux trouver plus d'infos sur le site de Mercurial par ex ou le livre indiqué sur ce site.
Vous l'aurez compris, pour ma part j'ai choisi Mercurial, et j'en suis assez content. Pour Git je ne connais pas.
mes 2 cts.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 1.
Ben tu n'en a pas besoin pour svn.
Tu auras besoin d'être connecté lorsque tu as besoin du dépôt (commit, log, etc).
Tu en a pas besoins pour diff, revert, status, etc.
[^] # Re: Re:
Posté par alice . Évalué à 1.
[^] # Re: Re:
Posté par Étienne . Évalué à 2.
Combinaisons que tu fais bien sûr souvent. Tu n'as pas besoin d'accéder au repository pour :
- rajouter un élément
- supprimer un élément
- déplacer un élément
D'autant que des suppressions et déplacements d'éléments, ce n'est pas fréquent, alors des combinaisons qui nécessiteraient d'accéder au repository, je ne pense pas qu'on puisse qualifier leur fréquence de souvent
[^] # Re: Re:
Posté par alice . Évalué à 5.
Dans ma boite on utilise Subversion au quotidien, mais on rencontre ces problèmes régulièrement. Donc oui c'est suffisamment souvent pour être ennuyeux!
La seule raison qui ne nous fait pas migrer, c'est l'interface TortoiseSVN, sinon on serait déjà sous Mercurial ou GIT.
[^] # Re: Re:
Posté par Sylvain Sauvage . Évalué à 2.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 4.
facilement faisable avec SVN,
On cite un cas d'utilsation beaucoup plus commun que ne résoud pas simplement un DVCS
et bizarrement le mutisme est de mise.
http://linuxfr.org/~NoNo/26146.html#904627
ou encore comment géré les suavegardes de facon centralisées et
La sauvegarde qui est un aspect crucial en entreprise
http://linuxfr.org/~NoNo/26146.html#904641
La portablité laborieuse de git, un détail
C'est vrai On ne peut pas historiser en mode déconnecté, c'est vrai que je reste 6 mois hors de ma boîte et que je commite comme un fou.
La complexité de ce genre d'outil n'est qu'un détail insignifiant.
Ah au fai,t c'est vrai il y a plein de plugin avec la plupart des outils de tracking, tous les IDEs disposent tous d'une intégration avec SVN au contraire de vos DVCS , preuve tangible que les SVN fanboys ne sont que des moutons de panurge.
[^] # Re: Re:
Posté par abramov_MS . Évalué à 2.
Maintenant peut etre que je vais me servir de svn avec le plugin de openoffice.org :)
[^] # Re: Re:
Posté par alice . Évalué à -1.
Voilà, c'est ça!
Et bien je suis très content pour toi.
Ce qui est tangible c'est qu'ils voudraient imposer au monde entier leur amour inconditionnel pour un soft...
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 2.
Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.
Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Concernant les images, chartres graphiques, UML, XML (wtf, vous savez pas merger un xml ? ), ....
résoult guère le problème en général.
Tout est affaire de point de vue.
Bizarrement la technique de l'évitement est aussi de mise chez les prosélytes des DVCS
"Ca gère pas mais c'est pas grave."
La paille dans l'oeil, la poutre, et tout ce qui s'ensuit.
Les projets libres de taille importante gèrent beaucoup moins de fichiers de ce type là qu'en entreprise, donc forcément c'est moins important pour eux. Et si un dev est obligé de refaire le boulot 2 fois, ca n'a guère de conséquence car il ne s'en prendra qu'à lui même et ne rendra de compte à personne.
Ca rejoint ma remarque initiale , les DVCS ne sont pas des outils universels et se prêtent beaucoup mieux aux projets communautaires.
Sauvegarde de façon centralisé. Euh kékidi ? Il y'a un serveur de référence qui peut être sauvegardé sans problème.
Sauf que si un développeur développe une feature pendant un certains temps et ne push pas sa branche par négligence ou ignorance et que son disque crash tout son son travail est perdu.
Le dev svn ne perd que son dernier changeset.
Ou alors il faut déployer une solution de sauvegarde automatique sur les postes ce qui n'est pas toujours aisé en entreprise
Tout repose donc sur la vigilance du développeur
Quand à la dernière remarque, Rome ne s'est pas fait en un jour. Git est bien plus jeune que svn, et son intégration dans de nombreux outils va bon train (voir différents post dans ce thread). 2 ans après la sortie de svn, lorsque cvs était encore roi, aurai-tu continuer à utiliser cvs au lieu de svn ?
Sur ce point je suis réservé, git est conçu pour Linux et j'imagine qu'il faudra des changements importants pour qu'il soit acceptable sur Windows.
Ce sera un frein à son adoption dans les IDEs et autres outils mutli-plateformes.
Sur ce point, je suis plus optimiste pour bazaar-ng et mercurial.
[^] # Re: Re:
Posté par zul (site web personnel) . Évalué à 2.
- je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier
- perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.
- si le développeur est incompétent / négligeant / ignorant, mon premier souci n'est probablement pas celui que tu décris, sachant que les disques durs ca lache pas si souvent que ça. Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).
- git est écrit pour Linux, mais tourne concretement sur n'importe quel système Posix. Pour Windows, il reste du boulot, je ne sais pas trop où ils en sont. Je n'ai personnellement pas d'action pour git. Hg, monotone (on l'avait pas encore cité), bazaar-ng ou cie, je n'en ai cure, tant que c'est décentralisé (il se trouve que là ou je travaille, on utilise plus git qu'autre choses).
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 1.
- je continue à penser qu'il s'agit surtout de problèmes de communications et d'organisations (que j'ai pu constaté par moi-même dans le passé). svn permet ici d'améliorer un peu la situation, mais le problème reste entier
SVN résout ce problème complètement:
Se prémunir que 2 personnes accèdent concurremment à une ressource.CQFD
Nul n'est à l'abri d'un oubli.
Que des questions d'organisation subsistent peut -être mais c'est décorrélé du pb qui nous préoccupe.
J'aurais préferé que tu nous répondes sur la façon dont tu gérerais ce pb alors je t'aide un peu.
1- isoler lorsque c'est possible les fichiers dans une même arborescence (specs, fichier UML) et utiliser une branche partagée lorsque l'outil support le modèle centralisé.
2- pour les autres fichiers, déployer des hooks sur chacun de postes (avec le problématiques qui s'ensuivent , portage, droits, ...). Le hook accédera à un serveur central pour gérer l'exclusivité. (Réinventons la roue )
Dommage que pour des considérations de securité certains DVCS (hg, git je sias pas) choisissent délibérément de ne pas propager les hooks, du coup c'est aux admins de s'en charger.
Ou mieux il pourrait prendre en charge ce ca en natif aavec ses prtopres métadonnées (flag particulier sur un fichier qui indique qu'on doit réserver un fichier sur une archive particulière, debranchable en locaal si nécessaire )
En même temps pour quelqu'un qui travaille en mode deconnecté 6 mois durant je comprend que ca ne serve pas. Autant modifier toutes les specs a gogo et tout refaire après. Pas la peine d'implementer ce use case dans un DVCS pour les rares fois où on en a besoin.
perso, nos $HOME sont backupés, donc pas de soucis particulier. Même quand j'ai travaillé dans une entreprise, avec du Windows, on travaillait toujours sur des disques réseaux backupés. Voir la compétence de vos sysadmins ensuite.
A vi vos espaces de travail sont sur des disques réseaux backupés.
Ca aide vachement à travailler en mode deconnecté ca. Il me semblait que c'était l'argument massue en faveur des DVCS.
La seule solution est de déployer une solution de sauvegarde automatique à la connexion, ce qui est techniquement plus complexe et nécessite une bonne organisation derrière
Par contre, svn, git ou hg, j'ai tendance à regarder tous les commits qui passent, et svn n'empêchent pas les commits foireux (avec du code commenté pour les tests pas décommentés, des trucs de débug sans queue ni tête ...).
SVN n'empêche pas non plus de travailler sur de branches parallèles et de confier les merges à une équipe d'intégration qui est chargée d'approuver de ou de rejeter les modification su les branches maître.
Le modèle user/team centric est parfaitement applicable
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 2.
Pour les commit locaux ,on dispose des changelist
Pour les plus exigeants rein n'empêche de se créer un repository local et avec un peu de scripting, on extrait une arbo et on la remonte dans son dépôt local.
Ensuite, on se crée un workspace et on commite autant qu'on veut.
Pour peu qu'on dispose d'une branche dédiée sur son dépot central on commite chacune des révisions de son dépot local et le tour est joué.
N'importe qui pourra incorporer les changeset commités dans sa propre branche sur le serveur.
Une fois le travail fait c'est toujours applicable (ca doit être peu ou pro le principe de svk) mais j'imagine que si c'est si essentiel nul doute qu'on verra emerger une solution de ce type
Le bisect, faisable simplement
...
Pour mon cas d'utilsation en revanche rien de bien convaincant du coté des DVCS actuels, tant qu'il ne décideront pas de l'implémenter.
MAis je ne les connais pas tous.
[^] # Re: Re:
Posté par abramov_MS . Évalué à 2.
Ensuite, on se crée un workspace et on commite autant qu'on veut.
Euh comment dire c'est simple ca comme utilisation... Tu montres tout de meme dans tes posts que tu es un "power-user" de SVN et donc que tu le connais sur le bout des doigts ce qui est le cas pour pas beaucoup de monde, je pense que tu en conviendras. Pour une utilisation ponctuel SVN n'est a mon avis pas le plus simple mais c'est une opinion toute personnelle encore une fois.
Enfin bon comme dit plus haut chacun fait ce qu'il veut. Ceux qui preferent les trucs centralise a la SVN ca tombe bien cela existe et les autres (dont moi) qui preferent les trucs simple et non centralise cela existe aussi avec les differents DVCS.
C'est possible qu'avec plus ou moins d'effort on arrive au meme resultat que git avec svn. Il n'empeche que git existe a des passerelles avec SVN en particulier (du coup tu dois pouvoir meme melanger le meilleur des deux mondes.)
C'est ca qui est bien avec le libre, le choix existe et chacun prend ce qui lui convient le mieux.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
[...]
> Je connais mal git et mercurial.
Peut-être que ceci explique cela. Pour avoir pas mal utilisé git et subversion, franchement, tout seul ou pas, y'a pas photo, git est très loin devant. Rien que pour les perfs, avoir un repository facile 2 fois plus petit en espace disque, et à peu près toutes les opérations courrantes pour lesquelles l'outil répond instantanément, c'est déjà un plus considérable. Après, je pourrais parler des vrais avantages de Git sur Subversion, mais bon ...
[^] # Re: Re:
Posté par IsNotGood . Évalué à -1.
Franchement, t'es un développeur ?
Tu pisses 500 000 lignes de code par jour ?
Ou tu t'amuses à alimenter ta gentoo à coup de checkout ?
Lorsque je développe, si j'attend 5 minutes subversion dans une journée, c'est vraiment le maximum de chez maximum.
M'enfin, contrairement à toi je ne pisse pas 500 000 lignes de code par jours ni ne fait un "svn update" de tous les sources installés sur ma bécane.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
alias ls='sleep .5; ls'
alias cd='sleep .5; cd'
Bosses avec ça une journée, et tu comprendras ce que je ressent quand j'utilise SVN tout en connaissant Git.
Sinon, j'ai toujours pas compris le rapport entre les perfs, le fait de bosser seul, ou le checkout de Gentoo.
Allez, fais-nous rire : tu as utilisé Git combien de temps dans ta vie pour le comparer à SVN ?
[^] # Re: Re:
Posté par Étienne . Évalué à 3.
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
206
$ cat ~/.zsh-history | grep svn | wc -l
139
$ cat ~/.zsh-history | grep cd | wc -l
298
$ cat ~/.zsh-history | grep ls | wc -l
228
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 3.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
Je l'ai utiliser très très occasionnellement et j'ai rien fait d'exitant.
A toi de nous impressionner. Tu utilises Git depuis combien de temps ? Tu tapes combien de commandes Git dans la journée ? 500 ? 2000 ?
WhaooOO !!!
[^] # Re: Re:
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
Rien d'impressionnant, mais je crois que quand je compare Git et SVN, je sais à peu près de quoi je parle.
Toi, tu te permet de critiquer Git, alors que de toute évidence, tu ne sais absoluement pas de quoi tu parles, tu ignores tout de cet outil. Je sais bien qu'on est Vendredi, mais si tu pouvais avoir des arguments pour troller, ça serait cool, ça élèverait le débat.
[^] # Re: Re:
Posté par B16F4RV4RD1N . Évalué à 2.
Pour les centralisé comme SVN, je comprends qu'il y a un serveur sur lequel les développeurs synchronisent leur code, mais pour le distribué, comment est-ce que ces données sont redistribuées justement ? C'est un genre de p2p ? Ou alors il y a un serveur qui centralise les contributeurs et leur permet d'échanger les données qui sont uniquement stockées sur leurs ordinateurs et non pas sur ce serveur ?
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Re:
Posté par abramov_MS . Évalué à 1.
Exemple: (Je reprend celui du tutoriel)
Bob clone le repository de Alice chez lui
il fait des changement et les commit dans son repertoire de travail a lui
Alice regarde les changements fait par bob sur le repertoire de bob
les appliques ou pas
Alice fait ses changements dans son repertoire a elle
Bob regarde les changement de Alice dans son repertoire a elle
etc....
Donc en fait chacun travail sur sa propre branche sans avoir besoin d'etre connecte a un serveur pour faire le moindre commit vu que le commit est locale.
D'un autre cote tu veux tout mettre sur un serveur a la facon cvs et bien c'est possible et tu balances les commit de ton boulot quand tu le veux, c'est a dire que tu commit chez toi autant de fois que tu le souhaites et tu envoies sur le serveur uniquement lorsque tu es connecte ou que tu es content de tes changements.
Avec un cvs like si tu as pas acces au serveur, tu ne peux pas faire de commit et tu as interet a garder trace de tes changements tout seul ce qui est un peu pas tres pratique avec git c'est lui qui s'occupe de ca. (Enfin ca fait longtemps que je me suis pas servi de cvs du coup je dis peut etre des betises). Mais je dois avouer que j'adore le fait de ne pas avoir un serveur central pour garder mes changements mais un simple repertoire .git dans mon repertoire de travail.
De plus, je sais pas si c'est faisable avec svn ne l'ayant jamais utilise, la gestion des branches est ultra-simple et tu peux avoir des branches ou tu t'amuses a tout casser tout en gardant celle qui fonctionne sans avoir besoin de dupliquer le projet.
[^] # Re: Re:
Posté par Ludovic Gasc . Évalué à 4.
[^] # Re: Re:
Posté par NiCoS . Évalué à 7.
Pas d'accord. Perso, je code tout seul sur un projet. L'intérêt que je vois dans mercurial sur svn par ex, c'est que je peux commiter dans le RER et ensuite envoyer mes commits sur mon serveur via un hg push. En cas de revert, j'ai une granularité plus fine que si je devais commiter sur le dépot svn présent sur mon serveur.
Faire la même chose avec svn était nettement plus complexe.
[^] # Re: Re:
Posté par liberforce (site web personnel) . Évalué à 4.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 4.
pas d'accord du tout ! Même si tu est seul, ça peut être intéressant de pouvoir versionner ton projet. Et utiliser quelque chose de très lourd comme subversion, non merci.
Perso, j'utilise bazaar-ng, car c'est le premier que j'ai utilisé, il permet d'utiliser les dépots svn de manière transparente (donc je n'aurais plus jamais a utiliser svn :) et enfin il dispose d'une version native python.
Donc, avec subversion, tu dois créer un repository quelque part sur ta machine ou tu as plein de place pour y stocker tout et n'importe quoi.
Alors qu'avec bazaar (ca doit aussi marcher avec git ou mercurial), je me met dans le dossier que je veux versionner, je tape bzr init et c'est fini. De plus je n'ai pas de problème de cohérence. Les révisions sont stockées au même endroit que ma version de travail, pas dans un repository ailleurs.
[^] # Re: Re:
Posté par Bozo_le_clown . Évalué à 0.
C'est vrai que créer un repository avec un fs sous SVN c'est super compliqué.
Ah ouais si après tu veux partager avec d'autres c'est plus facile. tu n'as pas à faire une moullinette pour créer un branche dans un repository partagé et remonté les révision que tu as commité dedans.
Bon ben si t'es flemmard svk est ton ami (écrit en perl en plus puisque tout le monde aime ça). Tu as le beurre et l'argent du beurre et notamment des plugins d'integration avec la quasi totalité des IDEs et des GUIs à ne plus savoir qu'en faire, une architecture roubuste,c coue pour être portable. Mais ca ne compte pas.
Sinon pour faire des sauvegardes centralisé du travail de tout le monde dans une entreprise faut avoir confiance en ses employés.
Gare à celui qui oublie de faire un push de sa branche sur le miroir.
En cas de crash disque, c'est bon pour la productivité ça.
Avec SVN tu perds juste le travail en cours que tu n'as pas encore commité.
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
$ mkdir -p $HOME/svn/$PATH
$ svnadmin creeate $HOME/svn/$PATH
$ svn import -m "import initial" $HOME/$PATH file://$HOME/svn/$PATH
$ svn co file://$HOME/svn/$PATH $PATH
Et voila. Après du change $PATH par ce que tu veux et l'affaire est pliée.
[^] # Re: Re:
Posté par Mildred (site web personnel) . Évalué à 2.
Soit je me crée un seul repository dans mon homedir. mais je trouve ça très crade. Car ça veut dire que tous mes projets vont être mélangés. Si un jour j'ai un projet qui grossit, il fera grossir mon repository. Et si mon repository devient trop gros, il pourrait ne plus tenir sur le disque dur de mon laptop et je pourrais le migrer sur mon disque dur externe. Et cela veut dire que pour tous mes projets, je devrais brancher mon disque dur externe (ce que je fais très rarement) ... même si c'est un petit projet.
Je préfère de loin utiliser bazaar.
Une des fonctionnalités qui me fait choisir bazaar, c'est justement que tout est stocké dans le même dossier.
Avant de conaître bazaar, je m'étais fait un dépôt subversion quelque part. Sauf qu'au bout d'un moment je ne savais plus trop ce qu'il y avait dedans, lorsque je regardais son contenu, je ne comprenait rien ... et j'ai fini par l'abandonner.... au profit des commandes RCS ci et co ... et de script shell fait main.
Je peux comprendre que subversion soit bien pratique dans certains cas. mais dans mon cas (je veux juste avoir un système qui enregistre les révisions de mes fichiers) je trouve subversion trop lourd a utiliser. Cela implique de séparer ton projet en deux endroits (le repository et la copie de travail) ... et aussi, cela t'empêche de facilement sauvegarder un seul projet parmi d'autres sur le repository ... car justement le repository subversion fait un tout qu'on ne peux pas sparer si facilement (il y a surement des moyens, mais ce n'est pas aussi simple qu'un mv).
Je ne dénie pas les qualités de subversion, je trouve juste qu'il ne correspond pas a mon besoin. Et qu'il y a d'autres logiciels qui correspondent bien mieux.
Mildred
[^] # Re: Re:
Posté par IsNotGood . Évalué à 0.
Et j'ai nul part critiquer bazard-ng.
Mais faut pas pousser non plus. Tu passes ton temps à critiquer subversion sur des conneries. Du genre "tiens, et si ce matin je me faisait un dépôt en 2 secondes juste pour le plaisir de voir que ça prend 3 secondes de moins que Subversion".
Créer un dépôt est une activité accessoire. Savoir s'il faut en faire qu'un ou deux car une partie sera peut-être indépendante à l'avenir demande de la réflexion. Je passe beaucoup, beaucoup, beaucoup plus de temps à faire des "svn diff", "svn log", fouiller dans bugzilla pour le mettre à jour après une correction de bug et récupérer sa référence pour la mettre dans le log svn qu'a faire des "svnadmin create" le matin. Je fais un "svnadmin ...." pour 50 000 "svn diff|status|commit|update|merge". Et toi ?
[^] # Re: Re:
Posté par Moonz . Évalué à 2.
[^] # Re: Re:
Posté par abramov_MS . Évalué à 4.
J'ai jamais aime cvs avec pour raison principale le fait de devoir un serveur pour le bousin et etre totalement dependant de ca.
Un truc que j'ai trouve genial avec git c'est que je veux commencer un projet:
mkdir monproject
cd monproject
git init
et voila c'est fait pas besoin d'autre chose. Le truc encore plus top c'est que par exemple, j'ai la flemme de prendre mon portable pour aller chez mes parents (qui n'ont pas internet) mais j'ai un truc important a finir. Je prend ma petite cle usb je copie le repertoire du projet dessus, je branche la cle sur le pc de mes parents et je peux continuer a introduire les revisions comme je le souhaite.
Cela permet aussi d'avoir un backup physique des revisions vu qu'il suffit de sauver le repetoire du projet. Enfin je m'en sert probablement mal, pas de facon optimale mais il convient a mes besoins a moi car ca marche point barre et c'est ultra simple (surtout avec git-gui...)
# Mes 2 centimes
Posté par Jérôme Pinot (site web personnel) . Évalué à 3.
Cela dit, que choisir entre Git et Mercurial ?
C'est probablement plus une affaire de gout qu'autre chose.
Pour ma part, j'ai choisi Git depuis un moment déjà. Il était plutôt complexe à utiliser directement à ses débuts mais il a fait d'énormes progrès dans le domaine. Pour moi, Git a passé l'épreuve du feu. Avoir été choisi pour gérer le kernel Linux, Xorg ou Wine est une preuve indéniable de qualité originelle, ou du moins acquise. De nombreux projets et forges l'on choisi. C'est rassurant : s'il y a des bugs, ils seront vite repérés et corrigés. D'autre part, les outils tiers se développent effectivement.
La critique que je ferai sur Git est le fait qu'il soit difficile de remonter dans l'historique d'un fichier. Le modèle de gestion est plutôt basé sur l'historique de tout l'arbre des sources par patches. Si tu veux suivre un seul fichier, c'est donc un peu compliqué. Si tu veux suivre l'évolution de ton projet dans sa globalité, c'est simple.
Je connais très mal Mercurial, je ne vais donc pas en parler ici. Je ne l'ai pas choisi car je ne suis pas très fan de Python (surtout sur un serveur) et je n'ai pas très bien compris l'intérêt de l'utiliser pour coder un DSCM sachant qu'on peut très bien faire sans. Mais bon, l'égout et les couleuvres...
[^] # Re: Mes 2 centimes
Posté par Boa Treize (site web personnel) . Évalué à 3.
Un point qui reste bien différentiateur est le support Windows, sous lequel Mercurial marche très bien, alors que pour Git il y a un écart sensible par rapport à la version Linux.
(Moi j'utilise un peu les deux pour mes projets perso.)
[^] # Re: Mes 2 centimes
Posté par 태 (site web personnel) . Évalué à 1.
Mais git utilisant perl ne te choque pas ?
[^] # Re: Mes 2 centimes
Posté par IsNotGood . Évalué à 4.
Puisque l'utilisation de python le choque, il est normal que l'utilisation de perl ne le choque pas.
[^] # Re: Mes 2 centimes
Posté par Bozo_le_clown . Évalué à 1.
[^] # Re: Mes 2 centimes
Posté par tripa . Évalué à 1.
19 perl pour 54 shell au moment où je compte.
[^] # Re: Mes 2 centimes
Posté par Bozo_le_clown . Évalué à 1.
Est ce je peux utiliser Git simplement en appelant que des fonctions noyau.
Sinon ca me rappelle la première version de CVS en shell sur laquelle un fork avait été fait pour tout réécrire en C.
Ou encore ces infâmes hacks de Tom Lords sans queue ni tête qui ont données naissance à toutes cette ribambelles de forks mieux concus.
Vive Mercurial et Python alors.
Ou encore SVN écrit entièrement en C en se basant sur l'apache Portable Library à des fins de portabilité.
Ca en est où git avec windows à propos ?
Pas facile de rendre un portage aussi performant lorsqu'il n'a pas été prévu pour à la base.
Python aussi est portable.
[^] # Re: Mes 2 centimes
Posté par ribwund . Évalué à 3.
Parce que c'est plus rapide pour developper, que un scm bien foutu est très vite IO-bound (le core de mercurial est en C, le reste est en python, au final c'est pas si différent de git, sauf que le core est plus petit :)
Sinon perso mon problème avec git c'est le fait qu'il n'y ait pas d'historique au niveau fichier et que la taille prise par le dépot (j'aime pas l'architecture avec d'un coté on a un truc très gros de l'autre on a des packs qu'il faut faire manuellement et qui peuvent potentiellement etre dangereux pour l'historique -- on reecrit l'historique).
Dans mercurial je suis pas très fan de la gestion des branches (in-repo) si on utilise que des clones pour developper ses branches ca rox (et avec les hardlinks ca prend pas trop de place).
(D'ailleurs mercurial est aussi utilisé par des "grands": mozilla, sun, xen, etc)
# cogito
Posté par ploum (site web personnel, Mastodon) . Évalué à 1.
C'est une interface simplifiée à Git, ça semble intéressant.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: cogito
Posté par Jérôme Pinot (site web personnel) . Évalué à 5.
[^] # Re: cogito
Posté par ploum (site web personnel, Mastodon) . Évalué à 3.
Mes livres CC By-SA : https://ploum.net/livres.html
[^] # Re: cogito
Posté par tripa . Évalué à 2.
# Idées fausses
Posté par Ririsoft . Évalué à 10.
Je me permet de corriger quelques idées fausses véhiculées dans ton journal :
Depuis les annonces de Mozilla et OpenSolaris, je ne crois pas avoir croisé beaucoup de projets qui utilisent Mercurial
Sur la page d'Accueil de Mercurial on peut lire :
2007-12-12 NetBeans migrates to mercurial
2007-12-05 OpenJDK (aka Java) switches to Mercurial
2007-11-10 AsciiDoc has switched from Subversion to Mercurial
2007-04-20 Xine has switched from CVS to Mercurial.
Franchement du point de vue "qui a le plus de gros projets qui ont migré vers moi" Git et Mercurial sont équivalents.
je connais des hébergeurs spécialisés dans Git comme GitHub, mais pour Mercurial, je ne pense pas en avoir croisé.
Je reconnais qu'il y a moins d'hébergement Mercurial que Git, mais il y en a. http://sharesource.org/ est un bon exemple. De plus, comme Git, Mercurial permet d'avoir des dépôts en static http : tu peux très bien héberger ton projet sur tes pages persos de free.fr par exemple.
On pourrais blablater pendant des heures, mais à notre petit niveau comme au niveau de gros projets Git et Mercurial sont équivalents sur leurs fonctionnalités et leurs performances. Choisir l'un ou l'autre est une affaire de goût, c'est comme choisir entre zsh et bash, perl et python, c++ ou java (je caricature évidemment).
Cependant je crois que tu te trompes très fort en pensant que Git va écraser la concurrence et détriment du développement de Mercurial. En fait ils vont cohabiter : le noyau Linux par exemple a un dépot Mercurial synchronisé avec le dépot Git ...
Lequel choisir alors ?
C'est pas moi qui vais répondre à la question c'est toi, selon tes critères, tes projets et tes utilisateurs !
En ce qui me concerne, tu l'auras deviné, j'ai choisi Mercurial après avoir longtemps testé les deux.
Les raisons principales ont été la simplicité (il n'y a pas photo à mon avis, depuis les docs jusqu'à l'utilisation quotidienne), et la portabilité (je travaille avec des gens qui sont sous diverses platformes dont Windows, Linux et Mac OS).
Pour les allergiques à Python, je dirais une seule chose : Python ou pas, regardez la qualité du code de Mercurial et sa petite taille comparé au mammouth qu'est déjà Git. Pour moi c'est un gage de qualité, maintenabilité et extensibilité. Après qu''il soit en Python, Eiffel ou n'importe quel language à la mode m'indiffère !
[^] # Re: Idées fausses
Posté par Troy McClure (site web personnel) . Évalué à 4.
[^] # Re: Idées fausses
Posté par Ririsoft . Évalué à 3.
Et bien j'ai installé Mercurial sur mon compte en local très facilement sans aucune dépendance à gérer et grace à la "per user installation" : http://www.selenic.com/mercurial/wiki/index.cgi/UnixInstall#(...)
Un vrai régal !
[^] # Re: Idées fausses
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 6.
Autre chose, la documentation et la simplicité : c'est un point aussi important. les DCSM ayant une logique pas forcément simple à comprendre (surtout si on a beaucoup utilisé CVS ou subversion), il faut que la doc soit complète et pédagogique. C'est d'autant plus vrai si on veut attirer des contributeurs de tout horizons et de tout niveaux.
Sinon je rejoint chicha : non mais franchement, qu'est ce que ça peut faire pour un utilisateur que le logiciel machin soit fait en python ou C ?
[^] # Re: Idées fausses
Posté par Philippe F (site web personnel) . Évalué à 5.
De mon côté, je me suis posé la même question. Et j'ai choisi Mercurial pour les critères suivants :
- marche sous linux et windows comme un charme
- la doc est très bien foutue, prise en main instantanée de mon côté
- doc imbitable côté git
Critères subjectifs mais importants (c'est une hérésie de croire que les humains font des choix "objectifs" ) :
- j'aime bien python
- à la lecture de la doc, j'ai bien aimé la philosophie développée par les développeurs : un outil simple et compréhensible
- a contrario, j'ai pas trop aimé l'approche de Linus : je fais le coeur, démerdez-vous avec des scripts shell et perl pour que ca ressemble à un SCM
- j'ai lu plein de fois les docs sur git, je comprends toujours pas le 10e des fonctions ni de comment ça marche. J'ai lu une fois la doc sur mercurial et j'ai tout compris, à la fois sur les fonctionnalités et sur le coeur.
- une boite s'est montée autour de mercurial. Ca veut dire qu'ils ont des contraintes, genre outil bien documenté, stabilité sur plusieurs environnements, etc. Linus au contraire a dévéloppé un truc imbitable en imposant son fonctionnement à tout le kernel. Il n'a pas besoin que git soit simple à utiliser (il est plutôt pour l'élevation des barrières d'entrée sur la contribution au kernel). C'est donc les autres qui ont du se farcir le sale boulot de rendre git approchable. Cette différence d'approche rend mercurial plus convivial.
- hg c'est plus court à taper que git
Globalement, à part le truc de windows et le fait que git marche plus vite pour des projets énormes, je pense qu'ils se valent tous les deux et que donc le choix de l'un ou de l'autre est subjectif.
# Interface
Posté par Victor . Évalué à 3.
[^] # Re: Interface
Posté par NiCoS . Évalué à 2.
http://trac.edgewall.org/wiki/TracMercurial
[^] # Re: Interface
Posté par Bruno Michel (site web personnel) . Évalué à 5.
[^] # Re: Interface
Posté par oops (site web personnel) . Évalué à 2.
git en cours d'intégration.
[^] # Re: Interface
Posté par alice . Évalué à 2.
# Git par rapport à SVN
Posté par Loïc d'Anterroches (site web personnel) . Évalué à 2.
Les branches, je peux merger à n'en plus finir entre toutes mes branches sans me poser de questions car git garde l'historique des branches et ne va donc pas appliquer plusieurs fois des changements.
$ git branch
betterhtml
filterabstracts
htmltolatex
* local
master
J'ai 3 branches de travail, une local et une master que j'utiliser pour pousser ma version finale vers mon serveur:
$ git push monserveur master
Par exemple ma branch htmltolatex est une branche que je traine depuis longtemps car bon, l'implementation est longue. Quand je retravaille dessus, je fais juste un :
$ git pull local
Cela m'assure que tous les changements de ma branch local sont maintenant dans ma branche htmltolatex, je bosse dessus, je commit et je retourne vers mes autres fonctionnalités.
Quand j'ai un petit bug à fixer, hop, je fais une branch depuis local, je fixe, commit, merge dans local et master, push master sur le serveur, et retourne sur mes autres branches. Un petit pull pour reprendre les changements dans ma branch et je continue le boulot.
Et comme git-svn fonctionne très bien, je peux utiliser git même si en face il y a un dépôt subversion. Sinon les fonctionnalités avancées, je n'ai pas trop testé. Je trouve simplement très pratique de ne pas avoir besoin d'être "en ligne" pour faire mes commits.
# Avis perso
Posté par GPL . Évalué à -4.
Mercurial est pour ce qu'en sait une copie de GIT en python. Pour ma part, j'aime pas avoir des langages de haut niveau dans autre chose que des user applications.
Je trouve GIT très élegant. Un fois les concepts maîtriser... c'est beau.
Bref, GIT c'est beau, ça marche du tonnerre, c'est en C et sa license est la GPL.
[^] # Re: Avis perso
Posté par Putifuto . Évalué à 3.
et un gestionnaire de version est une application utilisateur.
[^] # Re: Avis perso
Posté par Troy McClure (site web personnel) . Évalué à 4.
Pas du tout ! git est une copie de mercurial en C
[^] # Re: Avis perso
Posté par Philippe F (site web personnel) . Évalué à 2.
# Pour les Subversion fanboys
Posté par alice . Évalué à 1.
1) un dossier et les fichiers qu'il contient doivent être renommés.
XXX_pouet/
+ XXX_pouet.h
+ XXX_pouet.cpp
Et je veux:
XXX/
+ pouet.h
+ pouet.cpp
TortoiseSVN m'oblige à le faire en deux fois, avec un commit intermédiaire...
2) Je veux fusionner depuis une branche, mais les fichiers ont été déplacés/renommés dans le trunk. TortoiseSVN me répond systématiquement "skip missing target"...
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.