Bozo_le_clown a écrit 1600 commentaires

Jusqu'à présent il existe toujours une solution techniquement possible sans s'arracher les cheveux pour résoudre vos cas d'utilisation:

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.

- 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

Cette fonctionnalité est appréciable et permettra d'atténuer les critiques faite à SVN en ce qui concerne les commit locaux, mais il ne s'agit pas d'une véritable branche locale.

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.

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.

Vi vi vi c'est marrant on a parlé de la bisection et montré que c'était
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.

Et bien sûr , tu as des témoignages et d'autres preuves irréfutables pour appuyer tes allégations et prouver qu'il ne s'agit pas de pur FUD

Je n'ai pas réussi à trouver avec quel outils de gestion de version quel était interfacé.

Peux t'on l'utiliser pour pour affecter des tâches à un changeset ?

Message subliminal:
Ne pas lire "Apple saybien"
Mais "Etre un consommateur responsable saymieu"

Une seule chose m'interpelle.

Pour arriver à tirer des prix aussi bas pour satisfaire des caprices de geeks sur quels leviers ont-ils appuyé. Le prix des composants, les fournisseurs... la main d'oeuvre ?

Et a présent tous les concurrents s'y mettent, la boite de Pandorre est ouverte.

Les ouvriers chinois sont-ils libres eux aussi ?

Et après on fait la morale à Apple.

""Vous pouvez reprendre une activité normale""

à été inventé par la FFF.

Je croyais qu'on devait plus parler de foot ici

Ok je comprends!

C'est pour que notre Joooohnny national, il ponctue toutes ses phrases par "Que" !

Que j'ai tout pigé maintenant :D

Meuh non
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

Et sous windows aussi il est plus rapide.
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.

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.

Donc le seul interêt c'est que l'étape "créer un repository" est inclue dans l'étape 'créer un workspace' puisque les 2 sont la même chose.
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é.

Prenons 1 autre cas d'utilisation qui me parait plus courant:

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.

Je ne vois ce qu'il y a de miraculeux là-dedans et en quoi un VCS centralisé ne le permettrait pas.

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.

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

Précision et correction:
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(...)

Qu'entends tu par wrapper ?

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.

Et lorsque Linus a parlé, la vérité est établie.

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(...)

Git écrit en perl, c'est une blague ...hein ?

Il ne faut pas confondre la gestion par fichier et la notion de changeset..

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

Merci du tuyau, je vais tenter ça, si ça peux m'éviter des WE à soigner les bécanes de la belle-famille

Intéressant mais pourquoi 3 partitions et pas 2 ?
Pour être sûr d'avoir compris, tu conserves l'image sur une partoche dédiée c'est ca ?