Le --amend réécrit le dernier commit en repartant du père.
La référence de branche locale est déplacée sur le nouveau commit. Il y a toujours une unique feuille dans la branche.
L'ancien commit est oublié et n'appartient plus à la branche. Il est dans le reflog.
Les branches sont des pointeurs … uniques.
Cette histoire de commit oublié (par un co, reset ou amend est le plus difficile à intégrer pour les novices avec git. C'est ingénieux mais déconcertant.
Pour travailler dans un même effort de développement: une branche ou plutôt un faisceau ou sous-graphe, il faut en fait travailler avec plusieurs références de branches (une locale et n de suivi). Leur association est purement formelle.
Hg fonctionne différemment. Tous les commits d'une même branche portent le même nom (fichier versionné dans le commit qui enregistre ces références). On peut donc se retrouver avec plusieurs commit feuilles qui portent le même nom (heads) qu'ils faut réconcilier. Le résultat est le même mais le concept est plus simple à appréhender.
C'est pour Hg que je le regrette pardon.
Même si une extension existe.
Sinon je pense que je me suis mal exprimé.
Git n'accepte pas plusieurs commits concurrents pour une même branche (feuilles d'un graphe). Il y a une seule référence de branche qui pointe sur un unique commit.
Avec Hg plusieurs commits concurrents peuvent appartenir à la même branche. D'où la commande hg heads. Chaque commit porte et persiste le nom de la branche associée.
Résoudre des conflits ne nécessite que de connaitre le nom des branches.
Avec Git les évolutions concurrentes sont gérées en assignant une référence de branche à chaque remote (branches de suivi) et à la référence locale: la branche de travail, et en les mergeant. Cette association n'est qu'une pure convention (dépend des refspecs). Ceci est plus souple et ça permet de réallouer des synchronisations, mais c'est plus complexe à appréhender.
C'est d'ailleurs assez déconcertant pour les devs novices d'intégrer qu'il faille créer une branche locale (hormis clonage de branche) avant de pouvoir travailler dedans.
En revanche le fait de ne pas persister les références de branches dans les commits simplifie la gestion des branche locales (Juste une réference à supprimer).
Ca intéresse qui, novice ou pas, de savoir comment est foutu un commit à part pour être sûr de passer pour celui qui y est à un dîner le mercredi soir ?
Un dev il a autre chose à faire qu'à comprendre ce qu'est un blob, un tree ou un commit.
Heureusement, on leur a épargné ça à nos devs.
J'avais oublié la plomberie et la porcelaine.
Je connais des développeurs qui ne supportent pas le rebase.
Tu gagne en lisibilité de l'historique certes, mais parfois le rebase fait un merge qui peut interférer avec ce que tu développais. Si tu corriges un conflit de merge sans maitriser ce que tu as réimporté ou si un conflit sémantique est introduit (http://martinfowler.com/bliki/SemanticConflict.html) tu n'as plus de traces de ton code initial.
Donc l'intétêt n'est pas évident pour tout le monde?
Si on était pas Vendredi, je dirais que Git est au VCS ce que Perl est aux langages
git reset --hard HEAD.
Amigo, t'embrouilles pas avec ceux qui te disent d'autres méthodes.
git reset --hard te sort d'un merge que t'as carabistouillé et même d'un rebase en cours (oublie l'abort).
Mais ATTENTION, ATTENTION jamais après avoir pushé. sinon FUYEZ !!! PAUVRES FOUS !!
Sauf lorsque tes admins sont prévoyants et veulent te protéger des représailles de tes petits camarades.
Pourquoi reset. Ben parce que ca te permet de remonter (ou descendre n'importe odans l'historique) et --hard parce que ca clean tout l'index et le workspace.
Puisqu'on vous dit que Git c'est une évidence.
Je le ferai un jour ce petit journal retour d'expérience d'un migration de 400 développeurs dans une DSI.
Promis
Pas besoin de comprendre les références locales et distantes avec Hg
Non, mais tu ne vois 200 références dans ton historique graphique.
Tous les commits portent la même reference de branche et le tien c'est le commit courant checkouté.
Si tu veux les distinguer avec plusieur remote "hg path"
On peut pas « explorer » les remote hormis la branche active ?
Bien sûr que sin mais par défaut tu sais que su as n heads à réconcilier pas besoin d'aller les pécher ou d'utiliser les subtilités du shell ou le star-merge. Tous les commit portent le même nom de branche et pas remote1/mabranche remote2/mabranche.
Gnééé pourquoi expliquer le GC à des débutants ?
Pour leur expliquer pourquoi il faut faire gaffe lorsque qu'on fait un reset hard ou un chechout détaché. Si Mr GC passe avant de ressusciter son commmit non référencé adieu le commit. Et s'il ne passe pas ils se posent toujours la question de savoir où est passé leur code. Erreur de débutant classique
Sous hg pas moyen de voir l'historique remote à moins de pull ??
Hg pull = git fetch.
Pas besoin d'expliquer que le pull enchaîne automatiquement fetch+merge (au sens git merge ou git rebase).
Pas de rebase par défaut (c'est un plugin) et pas de config sur la branche pour pull (merge ou rebase).
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg
Je vois même pas ce qu'il y a à expliquer (à part le principe basique d'un outil de versionning, quoi)
Essaie d'expliquer à des gens venant de Cleracase ou SVN qu'un commande de merge, des fois elle merge des fois elle merge pas elle update.
Là encore, hg comprend magiquement ce que tu veux faire ?
Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là (Pas facile de convaincre de l'intérêt à des codeurs Java qui utilisent une vue Synchronise ou qui clique droit dans le projet et voientt les fichiers à commiter s'afficher déjà cochés et pas les autres.
Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit
Et après,
-- mixed, en fait ma bonne dame ca empile les commits intermédiaires et ca vous met ca dans le workspace
et --soft dans l'index, Logique.
Allez savoir pourquoi:
Ben parce que en plus --mixed, en plus il écrase l'index donc faut bien mettre ca queqpart.
J'hésite quoi penser : soit hg est vraiment très fort à tout deviner à ma place, soit on peut rien faire avec hg.
J'ai une 3e explication: une petite dose de mauvaise foi ?
Et à mon avis la popularité de Git vient avant tout de son gourou.
Lorsqu'on a fait le choix pour ma boité il y a 2 ans maintenant, c'était un pari.
Je trouvais Hg mieux foutu (surtout sous Windows, plugin Eclipse excellent) mais avec l'adoption du projet Eclipse nous savions que Git finirait par l'emporter.
En bons moutons de Panurge, on a suivi mais tous les soirs je me gave de cachetons pour oublier que j'ai fait Hg cocu avec une plus moche mais mais plus riche.
J'utilse Git au quotidien et je l'enseigne à des …novices.
Je peux te dire qu'il est tout sauf intuitif.
Hg est beaucoup plus simple à comprendre car dispose d'un ensemble de commandes plus restreint, d'une interface en ligne de commande plus consistante et d'un ensemble de concepts plus restreint et moins complexe.
Pas besoin de comprendre les références locales et distantes avec Hg, pas de remote à comprendre hormis la branche active et la commande hg path. Pas besoin d'explique les detached head et le GC, pas besoin d'expliquer que les références sont comme les spaghettis de la belle et la bête que pour connaitre l'historique ou cloner une branche il suffit de tirer une nouille et tout vient avec.
Pas besoin d'expliquer la différence entre pull et fetch, entre pull avec merge ou rebase.
Pas besoin d'expliquer le fast-forward
Pas besoin d'expliquer les différence entre les options du reset.
…
Attention je ne dis pas que Git est moins bien je l'utilise (et je l'ai choisi par raison plutôt que par coeur pour toute ma boîte …), mais il n'est pas plus simple non.
Par défaut avec Hg, tu peux avoir plusieurs commit issus d'un commit initial sur un dépôt: les heads.
avec Git ce n'est pas possible. Tu as toujours des branches explicite et une branche référence toujours un commit (je ne parle pas des detached head on est dan un bare). Si tu pushes et qu'il y a 1 autre commit concurrent tu dois merger ou forcer à déplacer la référence de branche (lorsqu'on t'y autorise).
Si tu as plusieurs heads, ca signifie que tu as un conflit que quelqu'un d'autre peut prendre en charge en par un fetch dans son dépôt local.
Donc si tu bosses sur une seule branche et que tu veux laisser l'accès en écriture à ton dépôt ou au dépôt central c'est très pratique et simple mais ca montre ses limites même avec plusieurs clones locaux.
Si tu as besoin de plusieurs branches, elles existent. Comme avec Git ce sont des références (étiquettes) à un commit qui montrent dans quelle branche a été effectué le commit.
A la différence de Git, chaque commit de la branche porte cette étiquette alors qu'elle est unique et se déplace avec Git.
Je trouve ca assez intéressant car Git récupère l'historique d'une branche en extrayant le sous-graphe connexe mais il n'y a pas de moyen (hormis commentaire) de savoir si un commit intermédiaire avait été créé dans une
branche ou une autre.
Si tu pulles et que tu as 2 commits tu as plusieurs heads et donc un merge à résoudre. Pas de notion de référence locale et distante donc plus simple à appréhender, je pense (surtout pour ceux qui rebasent à l'envers, suivez mon regard dans le fond à droite).
Lorsque tu pushes le commit de ta branche rien ne change par rapport au explications du début. 2 commits concurrents de la même branche porte l'étiquette de branche (elle n'est pas déplacée) et un conflit est à résoudre (plusieurs heads).
Evidemment tu peux résoudre les conflits avant de pusher comme
Est-ce un problème d'avoir plusieurs heads:
Non pour les version importantes puisqu'elle portent un tag ?
Pour les outils tels que la CI (Jenkins) ca peut être gênant puisqu'ils ont besoin de se référer à une unique version.
Les spécialistes Hg nous diront peut-être comment on procède dans ce cas (un hook ?).
Ce que je regrette par contre c'est le fait que l'on ne puisse pas crée de branche locale avec Git. Ca devait être implémenté mais je crois que ca n'a jamais abouti, me trompe-je ?
Je ne sais pas non plus comment fonctionne le checkout partiel aujourd'hui.
En fait la seule vraie utilité de cette option selon moi c'est d'isoler des gros fichiers (des images, des binaires qu'on intègre sans source, …) dans un dépôt pour éviter de cloner 250 version d'un même fichier de 100 Mo dans son dépôt de travail.
C'est bien pourquoi leur rhétorique est : "De toute manière, les branches c'est nul, ce n'est pas agile, ca va à l'encontre de la CI, …".
Bon argument, mais mauvais prétexte.
C'est ce que je m'évertuais à expliquer mais visiblement je n'ai pas été clair.
Relis le lien que je t'ai donné qui fait la différence entre le continuous deployment et les approches agiles traditionnelles (Scrum) .
Avec les méthodes agile les livraisons ne sont pas conditionnées par le périmètre fonctionnel mais par le découpage du temps. On peur revenir sur ce périmètre mais pas sur la date de livraison (sprint). Les équipes ont parfois tendance à repousser les efforts d'intégration et de test à la fin (même avec de la CI derrière). Parfois elles sont à la bourre et bizarrement la course à l’échalote recommence comme au bon vieux temps du cycle en V. Et là ca y va à cou de branches temporaires ou de revert pour virer des stories … c'est l'effet mini-tunnel décrit par l'auteur.
Si on se met dans l'état d'esprit d'accepter que chaque User story complétée est potentiellement déployable (continuous deliveries) ou "pire" si l'on sait qu'elle est vraiment livrée (continuous deplopyment) dès qu'elle est prête pplutôt que de la grouper avec d'autre, alors plus d'effort d'intégration à la dernière minute.
Pour assurer ca, il faut pouvoir facilement désactiver une feature tant qu'il y des commits intermédiaire et que la story n'est pas complète ou de corriger rapidement (pas facile avec une appli dont on ne maîtrise pas le déploiement comme les applis mobiles).
Quand on ne peut pas garantir ça. Le seul moyen qui reste est donc une branche par feature qu'on intègre par merge d'es qu'elle est complétée même si c'est décrié par les agilistes puristes.
Pour assurer la CI. On peut automatiser le merge de chaque commit sur le trunk vers chaque branche de feature.
S'il casse le build, il faut la corriger illico. Du coup on reste en contact avec le trunk et plus de Big Bang merge.
voir ici : http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow
Utiliser du branching by abstraction n'a rien à voir avec l'outil de source hein… c'est pas fait pour combler un quelconque manque mais bien pour permettre d'offrir les features autrement ou d'avoir des migrations plus douces. Vraiment.
J'ai jamais dit le contraire. Relis-moi mais j'ai souvent entendu ce discours lorsque des devs SVN en détresse ne se sortaient pas d'un merge:
"Tfacon avec la CI on a plus besoin de branche."
"J'ai vu sur un forum que la feature toogling résolvait ce pb" , pour des applis mobiles niveau sécurité c'est top.
Tu peux appliquer des bonnes pratiques architecturales mais parfois un bon outil vient à la rescousse et les branches deviennent incontournables c'est tout.
Heu, en quoi ? 1 dépôt commun ne va pas dire que tu n'organises rien, bien au contraire.
Tout à fait.
Sauf que parfois des développeurs font des svn cp dasn tous les sens sans réfléchir aux conséquences de leur actes (surtout avec des equipes de projet différentes) et tu te retrouves avec du code d'un module qui n'a rien à faire à cet endroit et là le cauchemar commence pour s'y retrouver. Ca arrive moins si tu as des dépôts disjoints (ou alors à moins de forcer tout ca avec des hooks. SVN est déjà un monstre de perf.)
Alors là faut voir. C'est très variable comme affirmation.
Oui le découpage en composant est une opération délicate. Parfois le code est complètement disjoints et peu couplé.
Dans ce cas c'est largement préférable … notamment si tu veux migre vers un autre outil par exemple.
Sinon le trunk based development est un workflow et ne dépend pas de l'outil mais du contexte (architecture, type de produit, équipes, …)
J'ai peut-être mal compris, mais les deux cas permettent le déploiement en continu.
A un moment le trunk based montre ses limites si tu ne peux pas mettre en place le feature toggling.
Tu devras forcément créer des branche d'intégration pour une livraison même en agile (effet mini waterfall avec scrum décrit ici par exemple).
Le seul moyen de déployer en continu de manière fiable est de garder ton trunk toujours propre et d'implémenter chaque feature dans sa branche (parfois locale pour les DVCS) puis de l'intégrer et la livrer dès qu'elle est prête (cf lien sur Github plus haut) et non pas groupée avec d'autre lors de la prochaine livraison (sprint par exemple).
Le lien que tu montres semble corroborer mes propos.
Pour Google, il y a des projets complètement différents qui sont géré sous un même dépot Perforce, qui comme SVN
utilise "l'inter-file branching model" voir (Eric Sink paragrahe "two banchin models") mais qui contrairement a SVN sens sort mieux dans le name tracking lors des merge.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Git et Hg utilisent l'autre modèle dans lesquelles les branches sont des méta-données gérées par l'outil et sont distribués.
Il est donc impératif d'isoler les modules disjoints dans leur dépôt et de ne réserver le depôt unique que pour le code fortement couplé. C'est pourquoi j'expliquais comment transposer le branching ala SVN sous Git (solution 2)
Après c'est vrai que ce n'est peut-être pas la situation de FB mais si tu me relis bien tu verras que j'avais mis les balises pour les taquiner (trollday).
Pour Clearcase, le schéma que l'auteur présent est celui proposé par la surcouche UCM de Cleracase, mais l'auteur ment en disant que c'est le workflow par défaut. Il est possible, mais le trunk bas est possible puisque ce n'est que la version simplifié du mainline. Qui dit simplifié dit recherche de simplicité. Et en effet c'est préférable. De même qu'il est préferable d'éviter les branches lorsqu'on le peut (http://martinfowler.com/bliki/FeatureBranch.html)en modifiant son architecture (http://martinfowler.com/bliki/BranchByAbstraction.html, http://martinfowler.com/bliki/FeatureToggle.html,...) mais dans les 2 cas ce n'est pas toujours possible.
La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes… Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens…
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
En fait Facebook n'a pas migré de Git vers Hg mais de SVN vers Hg.
Au départ leurs code est hébergé sous SVN et ils souhaitaient continuer à fonctionner avec les caractéristiques de cet outil, tout en adoptant les avantages des DVCS. Ils ont donc toujours un dépôt central SVN mais clonent sous Git en local.
Le souci qu'ils rencontrent est un grand classique des équipes qui bossent sous SVN et qui ne veulent pas se prendre la tête à recréer un dépôt pour chaque nouveau projet. On se crée un sous-répertoire avec ses branches et tag ou alors un sous-répertoire sous trunk, branches et tags.
Quand on bosse avec SVN on fait juste un checkout du bon sous-répertoire et c'est marre.
Lorsqu'on utilise un dvcs, soit en clonant, soit en migrant l'historique à plat on rencontre plein de soucis.
Déjà, cloner un dépôt entier pour ne travailler que sur une sous-partie négligeable ça prend des plombes.
Ensuite on se retrouve à extraire tout à plat une arbo avec tous les projets qui servent à rien y compris le contenu des tags et branches.
Enfin, chaque commit fait un hash de tout le contenu alors que l'on travaille sur une portion disjointe.
Petit retour d'expérience
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
La première solution a pour avantage d’alléger le clone. Mais elle présente l'inconvénient de travailler à la mode SVN avec les même contraintes que cet outil (pas d'historique local) et en venant de SVN, on se retrouve toujours avec l'arborescence à plat des projets et toutes les branches , tags , …
A chaque fois qu'un dev d'un projet commite et push il pollue les devs des autres projet qui doivent faire des rebase/merge fast forward pour du code qui ne les concernent pas.
La 3ème solution ne convient pas car elle ne fait que masquer les répertoires inutiles.
Déjà, elle n'est possible qu'en ligne de commande. (Les IDEs ne l'implémentent pas). ensuite ça ne résout aucun des problèmes de performances (les clones sont toujours complets, les commit sur tout le contenu, …)
Pour s'en sortir, lorsqu'on a rencontré ce pb sur un projet voici les solutions envisageables.
1- Créer un dépôt par projet et remonter l'historique.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
La démarche:
git svn clone --tags --branches svn://<mon-depot-svn> <mon-depot-git-local>
Au besoin, ajouter l'option authors-file pour faire correspondre les comptes svn avec les auteurs de commit Git. Le fichier mes-auteurs.txt doit être renseigné.
git svn clone --tags --branches --authors-file=mes-auteurs.txt svn://<mon-depot-svn> <mon-depot-git-local>
Vérifier le contenu du dépôt local et recommencer l'import si besoin. Faire le ménage (suppression/renommage des tags/branches inutiles).
Pusher ses modifs sur le serveur central
git remote add server http://git..../<mon-depot-git-central>
git push --all server
git push --tags server
2 - Utiliser le clone par branche (point 2)
D'abord Migrer l'historique SVN tel quel dans Git dans un dépôt legacy. Créer un autre dépôt propre puis créer une branche par branche active de projet dans laquelle on recopie la dernière révision de la branche active du projet. On expurge tous les répertoires des autres projets. On commit et on pushe sur le dépôt central.
Ensuite il suffit de cloner les bonnes branches pour ses besoins.
Ceci reste tout de même contraignant par rapport à la façon de travailler avec SVN puisqu’il faut manipuler les branches avec des conventions de nommage. Ce n'est pas dans les habitudes des développeurs venant de SVN.
Cette solution est à appliquer lorsque le code est trop imbriqué (comme décrit plus haut). Pour les modules biens disjoints, on peut appliquer la première solution pour les isoler dans un dépôt (et utiliser submodule si besoin)
Voilà.
Encore une fois une bonne architecture et une bonne gestion de conf peuvent aider à sauver des BB phoques.
Nos petits amis de FB, n'ont visiblement pas envie de se prendre la tête avec cette migration (ou ont une archi toute pourite ???). Ils préfèrent filer un coup de main au projet Hg (parce que c'est plus simple pour eux AMHA, pas parce qu'il préfèrent Hg à l'usage, j'imagine que c'est plus facile de déployer un plugin en interne que de convaincre une communauté) en optimisant le point 3. Notamment ils font en sorte que les commits ne s'applique sur des hash des fichiers modifiés et non sur tout le contenu et ensuite ils optimisent le cache pour ne travailler que sur le sous-graphe connexe plutôt que sur tout l'historique.
Tant mieux pour ce projet libre. Mais pas sûr qu'ils échappent à terme à ne plus travailler comme des gorets (un vendredi on peut se permettre un petit troll) et à migrer.
Ah !
Et dans
"
La participation des entreprises aux logiciels libres touche des domaines différents aux sciences économiques et sciences "
Rien ne te choque.
J aurais écrit :La participation des entreprises aux logiciels libres touche des domaines différents comme les sciences économiques ou les sciences sociales.
Surtout, ce qui "nous" interloque en général (Moi et Moi) c est surtout que toutes ces pompeuses productions individuelles semblent émaner de plusieurs personnes. Un chercheur vaudrait il plusieurs grouillots?
La modestie n etouffe pas les doctorants.
Cette condescendance nuit a la fluidité du discours.
N est il pas , Charles Henri ?
En tout cas ça fait tache avec des fautes grammaticales grossières.
On y retrouve une vision assez partagée ici.
- Oui au droit d'auteur, non aux brevets de tout ordre.
- L'invention ou la découverte simultanée est permise par le droit d'auteur tout en évitant le plagiat
- La concurrence stimule l'effort de recherche alors que les brevets endiguent le progrès en décourageant les concurrents et en permettant au détenteur de se reposer sur ses lauriers
- Quels critères pour évaluer le bon investissement en recherche
- Les initiatives communautaires non exclusives encouragées,
…
Clairement les brevets ne sont pas liés intrinsèquement au libéralisme.
Seul point qui mérite débat et qu'un interlocuteur avait abordé ici-même (sans réponse d'ailleurs)
: Le domaine public
J'avoue que j'ai un peu du mal à me convaincre que le marché ne vas pas nous faire acheter de l'air en bouteille un jour alors qu'un peu de régulation maintenant changerait cette destinée, mais bon …
Rien qu'en lisant le résumé on sent le parti pris:
Reprenant l'idéal cybernétique de libre circulation de l'information, l'utopie du logiciel libre se présente comme une contestation de la vision néolibérale de la propriété intellectuelle,
Quelle est la définition du terme néoliberal hormis la définition consensuelle de personnes auto-convaincues que le libéralisme est forcément néfaste et emploie ce terme péjoratif comme d'autre parle de logiciels "privateurs"
La propriété intellectuelle est-elle inhérente au "néoliberalisme" comme le sous entend l'auteur ?
[^] # Re: Uchronie
Posté par El Titi . En réponse au journal Gtk to Qt - A strange journey. Évalué à 2.
Swing aussi est en perte de vitesse.
Java FX est censé le remplacer. Mais il n'est pas entièrement libéré.
[^] # Re: Uchronie
Posté par El Titi . En réponse au journal Gtk to Qt - A strange journey. Évalué à 5.
QtJambi, QtRuby, ….
http://qt-project.org/wiki/Category:LanguageBindings
[^] # Re: Qt > Gtk
Posté par El Titi . En réponse au journal Gtk to Qt - A strange journey. Évalué à 4. Dernière modification le 13 janvier 2014 à 15:50.
Absolument, ca revient au même: on adapte un outil à ses besoins.
Il n'en reste pas moins qu'en terme de productivité du développeur, y'a pas photo.
[^] # Re: Qt > Gtk
Posté par El Titi . En réponse au journal Gtk to Qt - A strange journey. Évalué à 9.
Rohhh !!! les vilains pragmatiques !
C'est bien mieux de détourner le langage C pour y introduire le paradigme objet.
[^] # Re: c'est une question de philosophie
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Le --amend réécrit le dernier commit en repartant du père.
La référence de branche locale est déplacée sur le nouveau commit. Il y a toujours une unique feuille dans la branche.
L'ancien commit est oublié et n'appartient plus à la branche. Il est dans le reflog.
Les branches sont des pointeurs … uniques.
Cette histoire de commit oublié (par un co, reset ou amend est le plus difficile à intégrer pour les novices avec git. C'est ingénieux mais déconcertant.
Pour travailler dans un même effort de développement: une branche ou plutôt un faisceau ou sous-graphe, il faut en fait travailler avec plusieurs références de branches (une locale et n de suivi). Leur association est purement formelle.
Hg fonctionne différemment. Tous les commits d'une même branche portent le même nom (fichier versionné dans le commit qui enregistre ces références). On peut donc se retrouver avec plusieurs commit feuilles qui portent le même nom (heads) qu'ils faut réconcilier. Le résultat est le même mais le concept est plus simple à appréhender.
[^] # Re: c'est une question de philosophie
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 1.
C'est pour Hg que je le regrette pardon.
Même si une extension existe.
Sinon je pense que je me suis mal exprimé.
Git n'accepte pas plusieurs commits concurrents pour une même branche (feuilles d'un graphe). Il y a une seule référence de branche qui pointe sur un unique commit.
Avec Hg plusieurs commits concurrents peuvent appartenir à la même branche. D'où la commande hg heads. Chaque commit porte et persiste le nom de la branche associée.
Résoudre des conflits ne nécessite que de connaitre le nom des branches.
Avec Git les évolutions concurrentes sont gérées en assignant une référence de branche à chaque remote (branches de suivi) et à la référence locale: la branche de travail, et en les mergeant. Cette association n'est qu'une pure convention (dépend des refspecs). Ceci est plus souple et ça permet de réallouer des synchronisations, mais c'est plus complexe à appréhender.
C'est d'ailleurs assez déconcertant pour les devs novices d'intégrer qu'il faille créer une branche locale (hormis clonage de branche) avant de pouvoir travailler dedans.
En revanche le fait de ne pas persister les références de branches dans les commits simplifie la gestion des branche locales (Juste une réference à supprimer).
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Petite question entre nous.
Ca intéresse qui, novice ou pas, de savoir comment est foutu un commit à part pour être sûr de passer pour celui qui y est à un dîner le mercredi soir ?
Un dev il a autre chose à faire qu'à comprendre ce qu'est un blob, un tree ou un commit.
Heureusement, on leur a épargné ça à nos devs.
J'avais oublié la plomberie et la porcelaine.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 1.
C'est de base dans Hg maintenant.
J'ignorais.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Que l'embarras du choix tue le choix parfois.
Hg se focalise sur la simplicité et propose des extensions pou ce qui est avancé là où Git en fait trop.
Et pour le rebase:
http://mercurial.selenic.com/wiki/MqExtension
http://mercurial.selenic.com/wiki/RebaseExtension
Je connais des développeurs qui ne supportent pas le rebase.
Tu gagne en lisibilité de l'historique certes, mais parfois le rebase fait un merge qui peut interférer avec ce que tu développais. Si tu corriges un conflit de merge sans maitriser ce que tu as réimporté ou si un conflit sémantique est introduit (http://martinfowler.com/bliki/SemanticConflict.html) tu n'as plus de traces de ton code initial.
Donc l'intétêt n'est pas évident pour tout le monde?
Si on était pas Vendredi, je dirais que Git est au VCS ce que Perl est aux langages
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2. Dernière modification le 10 janvier 2014 à 17:53.
C'est pas toi le gars qui m'a refait la leçon un peu plus haut sur Hg que ca fait tout n'importe comment.
Allez je ne t'en veux pas. Tu connais pas Hg et t'as oublié SVN.
Pense aux autres qui souffrent en silence, aussi.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 7.
git reset --hard HEAD.
Amigo, t'embrouilles pas avec ceux qui te disent d'autres méthodes.
git reset --hard te sort d'un merge que t'as carabistouillé et même d'un rebase en cours (oublie l'abort).
Mais ATTENTION, ATTENTION jamais après avoir pushé. sinon FUYEZ !!! PAUVRES FOUS !!
Sauf lorsque tes admins sont prévoyants et veulent te protéger des représailles de tes petits camarades.
Pourquoi reset. Ben parce que ca te permet de remonter (ou descendre n'importe odans l'historique) et --hard parce que ca clean tout l'index et le workspace.
Puisqu'on vous dit que Git c'est une évidence.
Je le ferai un jour ce petit journal retour d'expérience d'un migration de 400 développeurs dans une DSI.
Promis
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4.
Non, mais tu ne vois 200 références dans ton historique graphique.
Tous les commits portent la même reference de branche et le tien c'est le commit courant checkouté.
Si tu veux les distinguer avec plusieur remote "hg path"
Pas besoin d'expliquer que le pull enchaîne automatiquement fetch+merge (au sens git merge ou git rebase).
Pas de rebase par défaut (c'est un plugin) et pas de config sur la branche pour pull (merge ou rebase).
Après, je ne sais pas comment est supporté le rebase aujourd'hui pour Hg
Déjà y'a pas d'index par défaut avec Hg. Je l'avais oublié celle-là (Pas facile de convaincre de l'intérêt à des codeurs Java qui utilisent une vue Synchronise ou qui clique droit dans le projet et voientt les fichiers à commiter s'afficher déjà cochés et pas les autres.
Pis c'est tellement logique de rajouter à l'index pour marquer des conflit comme résolus pour des gens qui ont l'habitude d'utiliser un commande svn resolve, pour "resoudre" un conflit
Et après,
-- mixed, en fait ma bonne dame ca empile les commits intermédiaires et ca vous met ca dans le workspace
et --soft dans l'index, Logique.
Allez savoir pourquoi:
Ben parce que en plus --mixed, en plus il écrase l'index donc faut bien mettre ca queqpart.
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 8.
Et à mon avis la popularité de Git vient avant tout de son gourou.
Lorsqu'on a fait le choix pour ma boité il y a 2 ans maintenant, c'était un pari.
Je trouvais Hg mieux foutu (surtout sous Windows, plugin Eclipse excellent) mais avec l'adoption du projet Eclipse nous savions que Git finirait par l'emporter.
En bons moutons de Panurge, on a suivi mais tous les soirs je me gave de cachetons pour oublier que j'ai fait Hg cocu avec une plus moche mais mais plus riche.
Bon! On aurait pu passer sous SVN aussi … Ouf
[^] # Re: Mercurial vu par Facebook
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 9. Dernière modification le 10 janvier 2014 à 16:55.
J'utilse Git au quotidien et je l'enseigne à des …novices.
Je peux te dire qu'il est tout sauf intuitif.
Hg est beaucoup plus simple à comprendre car dispose d'un ensemble de commandes plus restreint, d'une interface en ligne de commande plus consistante et d'un ensemble de concepts plus restreint et moins complexe.
Pas besoin de comprendre les références locales et distantes avec Hg, pas de remote à comprendre hormis la branche active et la commande hg path. Pas besoin d'explique les detached head et le GC, pas besoin d'expliquer que les références sont comme les spaghettis de la belle et la bête que pour connaitre l'historique ou cloner une branche il suffit de tirer une nouille et tout vient avec.
Pas besoin d'expliquer la différence entre pull et fetch, entre pull avec merge ou rebase.
Pas besoin d'expliquer le fast-forward
Pas besoin d'expliquer les différence entre les options du reset.
…
Attention je ne dis pas que Git est moins bien je l'utilise (et je l'ai choisi par raison plutôt que par coeur pour toute ma boîte …), mais il n'est pas plus simple non.
[^] # Re: c'est une question de philosophie
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 4. Dernière modification le 10 janvier 2014 à 16:35.
C'est pourtant simple et quelqu'un t'a répondu.
Par défaut avec Hg, tu peux avoir plusieurs commit issus d'un commit initial sur un dépôt: les heads.
avec Git ce n'est pas possible. Tu as toujours des branches explicite et une branche référence toujours un commit (je ne parle pas des detached head on est dan un bare). Si tu pushes et qu'il y a 1 autre commit concurrent tu dois merger ou forcer à déplacer la référence de branche (lorsqu'on t'y autorise).
Si tu as plusieurs heads, ca signifie que tu as un conflit que quelqu'un d'autre peut prendre en charge en par un fetch dans son dépôt local.
Donc si tu bosses sur une seule branche et que tu veux laisser l'accès en écriture à ton dépôt ou au dépôt central c'est très pratique et simple mais ca montre ses limites même avec plusieurs clones locaux.
Si tu as besoin de plusieurs branches, elles existent. Comme avec Git ce sont des références (étiquettes) à un commit qui montrent dans quelle branche a été effectué le commit.
A la différence de Git, chaque commit de la branche porte cette étiquette alors qu'elle est unique et se déplace avec Git.
Je trouve ca assez intéressant car Git récupère l'historique d'une branche en extrayant le sous-graphe connexe mais il n'y a pas de moyen (hormis commentaire) de savoir si un commit intermédiaire avait été créé dans une
branche ou une autre.
Si tu pulles et que tu as 2 commits tu as plusieurs heads et donc un merge à résoudre. Pas de notion de référence locale et distante donc plus simple à appréhender, je pense (surtout pour ceux qui rebasent à l'envers, suivez mon regard dans le fond à droite).
Lorsque tu pushes le commit de ta branche rien ne change par rapport au explications du début. 2 commits concurrents de la même branche porte l'étiquette de branche (elle n'est pas déplacée) et un conflit est à résoudre (plusieurs heads).
Evidemment tu peux résoudre les conflits avant de pusher comme
Est-ce un problème d'avoir plusieurs heads:
Non pour les version importantes puisqu'elle portent un tag ?
Pour les outils tels que la CI (Jenkins) ca peut être gênant puisqu'ils ont besoin de se référer à une unique version.
Les spécialistes Hg nous diront peut-être comment on procède dans ce cas (un hook ?).
Ce que je regrette par contre c'est le fait que l'on ne puisse pas crée de branche locale avec Git. Ca devait être implémenté mais je crois que ca n'a jamais abouti, me trompe-je ?
Je ne sais pas non plus comment fonctionne le checkout partiel aujourd'hui.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
En fait la seule vraie utilité de cette option selon moi c'est d'isoler des gros fichiers (des images, des binaires qu'on intègre sans source, …) dans un dépôt pour éviter de cloner 250 version d'un même fichier de 100 Mo dans son dépôt de travail.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 3.
C'est bien pourquoi leur rhétorique est : "De toute manière, les branches c'est nul, ce n'est pas agile, ca va à l'encontre de la CI, …".
Bon argument, mais mauvais prétexte.
C'est ce que je m'évertuais à expliquer mais visiblement je n'ai pas été clair.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2. Dernière modification le 10 janvier 2014 à 15:52.
C'est bien ça.
Relis le lien que je t'ai donné qui fait la différence entre le continuous deployment et les approches agiles traditionnelles (Scrum) .
Avec les méthodes agile les livraisons ne sont pas conditionnées par le périmètre fonctionnel mais par le découpage du temps. On peur revenir sur ce périmètre mais pas sur la date de livraison (sprint). Les équipes ont parfois tendance à repousser les efforts d'intégration et de test à la fin (même avec de la CI derrière). Parfois elles sont à la bourre et bizarrement la course à l’échalote recommence comme au bon vieux temps du cycle en V. Et là ca y va à cou de branches temporaires ou de revert pour virer des stories … c'est l'effet mini-tunnel décrit par l'auteur.
Si on se met dans l'état d'esprit d'accepter que chaque User story complétée est potentiellement déployable (continuous deliveries) ou "pire" si l'on sait qu'elle est vraiment livrée (continuous deplopyment) dès qu'elle est prête pplutôt que de la grouper avec d'autre, alors plus d'effort d'intégration à la dernière minute.
Pour assurer ca, il faut pouvoir facilement désactiver une feature tant qu'il y des commits intermédiaire et que la story n'est pas complète ou de corriger rapidement (pas facile avec une appli dont on ne maîtrise pas le déploiement comme les applis mobiles).
Quand on ne peut pas garantir ça. Le seul moyen qui reste est donc une branche par feature qu'on intègre par merge d'es qu'elle est complétée même si c'est décrié par les agilistes puristes.
Pour assurer la CI. On peut automatiser le merge de chaque commit sur le trunk vers chaque branche de feature.
S'il casse le build, il faut la corriger illico. Du coup on reste en contact avec le trunk et plus de Big Bang merge.
voir ici :
http://testonsteroid.tumblr.com/post/14231829163/continuous-integration-flow
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
J'ai jamais dit le contraire. Relis-moi mais j'ai souvent entendu ce discours lorsque des devs SVN en détresse ne se sortaient pas d'un merge:
"Tfacon avec la CI on a plus besoin de branche."
"J'ai vu sur un forum que la feature toogling résolvait ce pb" , pour des applis mobiles niveau sécurité c'est top.
Tu peux appliquer des bonnes pratiques architecturales mais parfois un bon outil vient à la rescousse et les branches deviennent incontournables c'est tout.
Sauf que parfois des développeurs font des svn cp dasn tous les sens sans réfléchir aux conséquences de leur actes (surtout avec des equipes de projet différentes) et tu te retrouves avec du code d'un module qui n'a rien à faire à cet endroit et là le cauchemar commence pour s'y retrouver. Ca arrive moins si tu as des dépôts disjoints (ou alors à moins de forcer tout ca avec des hooks. SVN est déjà un monstre de perf.)
Sinon le trunk based development est un workflow et ne dépend pas de l'outil mais du contexte (architecture, type de produit, équipes, …)
A un moment le trunk based montre ses limites si tu ne peux pas mettre en place le feature toggling.
Tu devras forcément créer des branche d'intégration pour une livraison même en agile (effet mini waterfall avec scrum décrit ici par exemple).
Le seul moyen de déployer en continu de manière fiable est de garder ton trunk toujours propre et d'implémenter chaque feature dans sa branche (parfois locale pour les DVCS) puis de l'intégrer et la livrer dès qu'elle est prête (cf lien sur Github plus haut) et non pas groupée avec d'autre lors de la prochaine livraison (sprint par exemple).
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
Le lien que tu montres semble corroborer mes propos.
Pour Google, il y a des projets complètement différents qui sont géré sous un même dépot Perforce, qui comme SVN
utilise "l'inter-file branching model" voir (Eric Sink paragrahe "two banchin models") mais qui contrairement a SVN sens sort mieux dans le name tracking lors des merge.
Dans ces 2 outils, les branches et les tags sont des répertoires. Brancher est aussi simple que de copier un répertoire.
Git et Hg utilisent l'autre modèle dans lesquelles les branches sont des méta-données gérées par l'outil et sont distribués.
Il est donc impératif d'isoler les modules disjoints dans leur dépôt et de ne réserver le depôt unique que pour le code fortement couplé. C'est pourquoi j'expliquais comment transposer le branching ala SVN sous Git (solution 2)
Après c'est vrai que ce n'est peut-être pas la situation de FB mais si tu me relis bien tu verras que j'avais mis les balises pour les taquiner (trollday).
Pour Clearcase, le schéma que l'auteur présent est celui proposé par la surcouche UCM de Cleracase, mais l'auteur ment en disant que c'est le workflow par défaut. Il est possible, mais le trunk bas est possible puisque ce n'est que la version simplifié du mainline. Qui dit simplifié dit recherche de simplicité. Et en effet c'est préférable. De même qu'il est préferable d'éviter les branches lorsqu'on le peut (http://martinfowler.com/bliki/FeatureBranch.html)en modifiant son architecture (http://martinfowler.com/bliki/BranchByAbstraction.html,
http://martinfowler.com/bliki/FeatureToggle.html,...) mais dans les 2 cas ce n'est pas toujours possible.
[^] # Re: Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 2.
La raison est que du code avec des cycles de vie complètement différents est associé à un composant.
Il n'y a que les développeurs SVN pour prétendre le contraire.
Les mêmes qui défendent leur outil en arguant que les branches ne sont pas importantes et qu'on en a pas besoin en agilité, qu'on peut contourner avec le "feature flipping" ou le "branching by abstraction", simplement pour masquer les lacunes de leur outil. Les bonnes pratiques agiles n'empechent pas d'utiliser un bon outil. qui peut le plus peut le moins.
Outre, le fait que ca améliore les performances, le découpage en dépôts permet l'approche par composant: Les composants sont donc ensuite assemblés avec des versions différentes pour former l'application. Ils sont interchangeables.
Ceci renforce aussi la structuration du code, facilite le passage de code entre différentes équipes… Les raisons ne manquent pas.
Bref, c'est une bonne pratique que les équipes sous SVN oublient parfois à leurs dépens…
Concerant ton lien:
Depuis des années nous pratiquons le "trunk based development" dans ma boîte sous Clearcase avant de passer sous Git. D'où l'intérêt de créer un dépôt par composant avec son propre cycle de vie justement.
Les branches par release ne sont intéressantes qu'à partir du moment où plusieurs releases avec des lots de fonctionnalités différentes sont développées en parallèle ou lorsque un SI contient de nombreuses application en production avec des dépendances fonctionnelles. Dans ce cas il faut pouvoir respecter des contraintes de temps lorsqu'on doit livrer des versions d'application dont d'autres dépendent et qu'on est sur leur chemin critique.
Ce cas de figure n'est pas le plus commun surtout pour de petits projets ou de petites structures. Surtout avec les méthodes agiles ou le périmètre fonctionnel évolue au lieu d'être figé pour une livraison (pas de lots en parallèle).
Le trunk based ou le branching by feature (qui permet le déploiement en continu, comme nos amis de Github ) conviennent mieux.
Mais dans tous les cas faire correspondre un dépôt a un unique composant/projet avec son propre cycle de vie est préférable.
# Mensongeries
Posté par El Titi . En réponse au journal "Scaling Mercurial at Facebook". Évalué à 3. Dernière modification le 10 janvier 2014 à 10:56.
En fait Facebook n'a pas migré de Git vers Hg mais de SVN vers Hg.
Au départ leurs code est hébergé sous SVN et ils souhaitaient continuer à fonctionner avec les caractéristiques de cet outil, tout en adoptant les avantages des DVCS. Ils ont donc toujours un dépôt central SVN mais clonent sous Git en local.
Le souci qu'ils rencontrent est un grand classique des équipes qui bossent sous SVN et qui ne veulent pas se prendre la tête à recréer un dépôt pour chaque nouveau projet. On se crée un sous-répertoire avec ses branches et tag ou alors un sous-répertoire sous trunk, branches et tags.
Quand on bosse avec SVN on fait juste un checkout du bon sous-répertoire et c'est marre.
Lorsqu'on utilise un dvcs, soit en clonant, soit en migrant l'historique à plat on rencontre plein de soucis.
Déjà, cloner un dépôt entier pour ne travailler que sur une sous-partie négligeable ça prend des plombes.
Ensuite on se retrouve à extraire tout à plat une arbo avec tous les projets qui servent à rien y compris le contenu des tags et branches.
Enfin, chaque commit fait un hash de tout le contenu alors que l'on travaille sur une portion disjointe.
Petit retour d'expérience
Pour travailler sur des sous-ensemble les DVCS ne proposent que 3 solutions.
1 N'extraire que les derniers niveaux de commits (1 niveau correspond alors à une simple snapshot de SVN)
2 Ne cloner qu'une branche
3 Ne checkouter qu'un sous-répertoire et travailler dessus.
La première solution a pour avantage d’alléger le clone. Mais elle présente l'inconvénient de travailler à la mode SVN avec les même contraintes que cet outil (pas d'historique local) et en venant de SVN, on se retrouve toujours avec l'arborescence à plat des projets et toutes les branches , tags , …
A chaque fois qu'un dev d'un projet commite et push il pollue les devs des autres projet qui doivent faire des rebase/merge fast forward pour du code qui ne les concernent pas.
La 3ème solution ne convient pas car elle ne fait que masquer les répertoires inutiles.
Déjà, elle n'est possible qu'en ligne de commande. (Les IDEs ne l'implémentent pas). ensuite ça ne résout aucun des problèmes de performances (les clones sont toujours complets, les commit sur tout le contenu, …)
Pour s'en sortir, lorsqu'on a rencontré ce pb sur un projet voici les solutions envisageables.
1- Créer un dépôt par projet et remonter l'historique.
Ceci présente 2 contraintes. L'importation est trèèèèès longue et il faut que le dépôt initial soit propre en terme d'architecture (Par exemple, si 2 projets séparés dans 2 branches distinctes ont par la suite été gérés dans une même branche, ca ne marche pas).
La démarche:
2 - Utiliser le clone par branche (point 2)
D'abord Migrer l'historique SVN tel quel dans Git dans un dépôt legacy. Créer un autre dépôt propre puis créer une branche par branche active de projet dans laquelle on recopie la dernière révision de la branche active du projet. On expurge tous les répertoires des autres projets. On commit et on pushe sur le dépôt central.
Ensuite il suffit de cloner les bonnes branches pour ses besoins.
Ceci reste tout de même contraignant par rapport à la façon de travailler avec SVN puisqu’il faut manipuler les branches avec des conventions de nommage. Ce n'est pas dans les habitudes des développeurs venant de SVN.
Cette solution est à appliquer lorsque le code est trop imbriqué (comme décrit plus haut). Pour les modules biens disjoints, on peut appliquer la première solution pour les isoler dans un dépôt (et utiliser submodule si besoin)
Voilà.
Encore une fois une bonne architecture et une bonne gestion de conf peuvent aider à sauver des BB phoques.
Nos petits amis de FB, n'ont visiblement pas envie de se prendre la tête avec cette migration (ou ont une archi toute pourite ???). Ils préfèrent filer un coup de main au projet Hg (parce que c'est plus simple pour eux AMHA, pas parce qu'il préfèrent Hg à l'usage, j'imagine que c'est plus facile de déployer un plugin en interne que de convaincre une communauté) en optimisant le point 3. Notamment ils font en sorte que les commits ne s'applique sur des hash des fichiers modifiés et non sur tout le contenu et ensuite ils optimisent le cache pour ne travailler que sur le sous-graphe connexe plutôt que sur tout l'historique.
Tant mieux pour ce projet libre. Mais pas sûr qu'ils échappent à terme à ne plus travailler comme des gorets (un vendredi on peut se permettre un petit troll) et à migrer.
[^] # Re: Médiocrité de l'expression
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 3.
Ah !
Et dans
"
La participation des entreprises aux logiciels libres touche des domaines différents aux sciences économiques et sciences "
Rien ne te choque.
J aurais écrit :La participation des entreprises aux logiciels libres touche des domaines différents comme les sciences économiques ou les sciences sociales.
Surtout, ce qui "nous" interloque en général (Moi et Moi) c est surtout que toutes ces pompeuses productions individuelles semblent émaner de plusieurs personnes. Un chercheur vaudrait il plusieurs grouillots?
La modestie n etouffe pas les doctorants.
Cette condescendance nuit a la fluidité du discours.
N est il pas , Charles Henri ?
En tout cas ça fait tache avec des fautes grammaticales grossières.
[^] # Re: Merci
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 3.
Relisez aussi la position de Rothbard, un libertarien qui fait autorité:
http://lemennicier.bwm-mediasoft.com/displayArticle.php?articleId=197
On y retrouve une vision assez partagée ici.
- Oui au droit d'auteur, non aux brevets de tout ordre.
- L'invention ou la découverte simultanée est permise par le droit d'auteur tout en évitant le plagiat
- La concurrence stimule l'effort de recherche alors que les brevets endiguent le progrès en décourageant les concurrents et en permettant au détenteur de se reposer sur ses lauriers
- Quels critères pour évaluer le bon investissement en recherche
- Les initiatives communautaires non exclusives encouragées,
…
Clairement les brevets ne sont pas liés intrinsèquement au libéralisme.
Seul point qui mérite débat et qu'un interlocuteur avait abordé ici-même (sans réponse d'ailleurs)
: Le domaine public
J'avoue que j'ai un peu du mal à me convaincre que le marché ne vas pas nous faire acheter de l'air en bouteille un jour alors qu'un peu de régulation maintenant changerait cette destinée, mais bon …
[^] # Re: Merci
Posté par El Titi . En réponse à la dépêche Petite sélection de mémoires publiés après 2010. Évalué à 7.
Pas moi par contre.
Rien qu'en lisant le résumé on sent le parti pris:
Quelle est la définition du terme néoliberal hormis la définition consensuelle de personnes auto-convaincues que le libéralisme est forcément néfaste et emploie ce terme péjoratif comme d'autre parle de logiciels "privateurs"
La propriété intellectuelle est-elle inhérente au "néoliberalisme" comme le sous entend l'auteur ?
Lisez cet excellent article de cet autre auteur au sujet de la PI:
http://lemennicier.bwm-mediasoft.com/displayArticle.php?articleId=125
et ce papier:
http://www.euro92.com/acrob/lemennicierbrevets.pdf
Attention on a affaire à un anarcho-capitaliste:
http://fr.wikipedia.org/wiki/Bertrand_Lemennicier