El Titi a écrit 3953 commentaires

Et sinon j'aime bien ce motto "Faites ce que je dis mais ne faites pas comme je fais" qui vous colle comme un gant

Condition générales (lisez surtout l'alinéa 20:)

iv. Ainsi, est-il notamment interdit au client de procéder à :
18. toute représentation, diffusion ou distribution, reproduction du service Budgea et de la documentation afférente, que ce soit à titre onéreux ou gracieux et notamment toute mise en réseau ou utilisation à des fins professionnelles ou commerciales ;
19. toute forme d'utilisation du service Budgea et de la documentation afférente, de quelque façon que ce soit, aux fins de conception, de réalisation, de diffusion ou de commercialisation de services similaires, équivalents de substitution et d'une documentation d'utilisation similaire, équivalente ou de substitution ;
20. l'adaptation, la modification, la transformation, l'arrangement du service Budgea et de la documentation afférente, pour quelque raison que ce soit, y compris pour corriger des erreurs ;

De la part d'un service qui détourne toutes les conditions des services bancaires environnants, je trouve ça assez cocasse.

Mignon la petite pub pour votre appli au passage (la seule qui a droit à un lien)

Je m'interroge sur cette appli justement.
Déjà la classique question de fonder tout un business model sur des fondations si mouvantes, le web scrapping:
Que se passe t'il le jour où une banque décide de modifier son site en profondeur et change de méthode d'authentification ?
Vous remboursez les clients dont l'interruption de service perdure ?

Concernant la sécurité. vous avez déjà indiqué quelque part (je ne sais plus où ici) que les données clientes sont encryptées. Dans le même temps votre algorithme d'affectation des catégories est basé sur du crowdsourcing. C'est donc bien que vous interceptez les opérations de vos clients non ?

Sinon, ce n'est pas que je vous fais pas confiance mais bon … Y'a t'il une appli de démo qui n'oblige pas à donner ses vraies coordonnées pour évaluer votre appli (du genre qui permette d'uploader un QIF et voir le résultat et qu'on puis détruire ensuite.

Enfin au niveau des fonctionnalités:
Votre appli permet-elle de saisir manuellement des opérations ?
Gère t'elle les débits différés et leur ventilation ?
Permet-elle de réaffecter ses catégories et de créer ses propres règles pour les opérations récurrentes même si votre algorithme de prévision est "révolutionnaire" ?

Certes mais une référence dans quel domaine ?

Celle d'un bureau codé comme des pieds …

A force de C#er sur les langages, ça finira sur un coup de forth.

Sinon le chef de projet a posté qu'il était encore vivant et si j'en juge par l'activité, il l'est:
https://qt.gitorious.org/qt-jambi/qtjambi-community/activities

Swing aussi est en perte de vitesse.
Java FX est censé le remplacer. Mais il n'est pas entièrement libéré.

QtJambi, QtRuby, ….
http://qt-project.org/wiki/Category:LanguageBindings

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.

Alors que chez Qt ils ont juste détourné un langage existant ?…

Rohhh !!! les vilains pragmatiques !

C'est bien mieux de détourner le langage C pour y introduire le paradigme objet.

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

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.

C'est de base dans Hg maintenant.

J'ignorais.

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

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.

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 o^dans 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.

Bon! On aurait pu passer sous SVN aussi … Ouf

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.

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.

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.

C'est bien ça.

Heurk.

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 p^plutô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.