El Titi a écrit 3948 commentaires

Ne pas commiter les changements du .classpath (le plugin pour Eclipse commite automatiquement les changements pour ce fichier, à chaque fois ça fout en l'air la configuration du projet chez chacun).


Ca le fera quelque soit l'outil.

Pourquoi le gérer en conf s'il est propre à chaque workspace ?


_Chez mes partenaires pour un projet, un verrou placé sur un fichier avec Eclipse était impossible à retirer, sauf en passant par la ligne de commande.

Le fonctionnement par lock ne correspond pas à l'usage par défaut de SVN.
Tu as essayé tous les plugins ?
vous utilisez Subversive ou Subclipse ?

C'est là où tu te trompes.

CC permet justement de s'adapter à quasiment tous les workflows de projet et est customisable à partir de sa version de base.
Tu peux utiliser un workflow prêt à l'emploi avec la surcouche UCM.

Avec Git, c'est la même chose, simplement il faut s'investir pour définir clairement son besoin.

Les spécificité des outils ne doivent intervenir qu'à la marge sinon c'est que l'outil n'est pas adapté.


Ton exemple montre juste que tu veux un truc prêt à l'emploi auquel cas il faut effectivement changer ses habitudes.
Si tu as affaire à un rejet il faut peut-être prendre le temps de comprendre le besoin et mettre en oeuvre une vraie conduite du changement. La Rache a ses limites (mais peut-être que vous n'êtes pas nombreux)


C'est juste que c'est mega lent, qu'il faut une équipe complète d'admin pour gérer un serveur pour 50 personnes.

Pour la lenteur je te donne pas tort (le poids de l'âge).
Pour l'équipe d'admin, c'est encore un pb d'organisation.
Chez nous une équipe de 3 admin gère une DSI de plusieurs centaines de développeurs en ayant proposé un worklow et un toolset associé.
Après on nomme un responsable GCL (un dev senior) par projet qui s'occupe de mettre en oeuvre le workflow et de coacher lorsque les devs de base en ont besoin. L'admin au sens propre: coté client et serveur + méthode + support ne monopolise que 3 ressources.

En même temps ce n'est pas à l'homme de s'adapter au worklow de l'outil mais à l'outil de s'adapter au cycle de vie du projet.

Les habitués de CC sont plus difficiles à convaincre simplement parce qu'ils savent maitriser un VCS digne de ce nom qui sait gérer des branches efficacement et merger sans se tromper. Ceux qui ont toujours défendu CVS et SVN face au vilain proprio m'ont toujours fait marrer:

- Les vues dynamiques qui te permettent de browser le dépôt sans le cloner avant
- possibilité de bosser en lock pessimiste ou optimiste
- les clones existent depuis toujours avec en plus des branches qui ne sont pas propres à un user mais dont la maitrise peut être transférée
- les tags sont des objets à part entière pas comme SVN
- les attributs qui font encore la pige aux properties de SVN
- le rename tracking
- les triggers sur plein de commandes qui permettent de le customiser à sa sauce


Bref il tient encore bien la comparaison avec Git et Hg


Mais aujourd'hui il a 20 ans, le monde à évolué et il montre ses lacunes
- privilèges d'accès lié à l'OS
- protocole verbeux
- plage de port au lieu d'un seul
....
C'est un outil adapté au travail en LAN mais beaucoup moins au travail distant

* Ne pas attendre 1 semaine qu'un admin te crée un compte sur le serveur
* ne pas attendre 15s avant de pouvoir commencer à éditer un fichier
* ne pas râler après Gaston qui est parti en vacances sans relâcher ses fichiers
* ne pas attendre 10 mns pour se créer une vue et une config spec et commencer à bosser sur un patch urgent
* ne pas se retrouver avec la moitié de son changeset commité et casser le build (transaction atomique), quoique UCM avec un projet multistream (rebase/deliver) revient exactement au même que Git avec push mais alors quelles emmerdes par ailleurs (gestion des baselines foiireuse, ...)
* poser un tag en 5 secondes
* branches locales
* Pouvoir bosser et commiter à la maison sans pb
* S'interfacer avec tous les outils open source ou cheaps de la planète et ne pas se limiter à Clearquest ou Jazz (integration JIRA=>Fisheye +Tasktop pas terrible, Hudson= galère, ..)
* suivre l'historique de ton projet et pas seulement au niveau du fichier (UCM pallie par contre)
* avoir un DSI heureux de ne pas gaspiller des dizaine de Keuros par an et acheter du super matos à la place
* Pouvoir bosser avec une boite exterieure sans que ce soit insurmontable (avec CC multisite obligatoire, ceux qui auront tenté de convaincre de mettre en place du multisite comprendront, .... ouvrir une plage de ports au lieu d'un seul port, qui paye les licences ? gestion du mastership, alignement des version des serveurs, ...)
* git bisset
* star merge
...

Par contre tu auras du mal à convaincre ceux qui aime la securité du reserved checkout (usage basique pour quelques scripts), de convaincre que le merge git de base est mieux que le merge 3 ways de CC
(le rename tracking se fait sur le hash et tente de deviner quand un fichier est renommé ce qui ne gère pas certains cas).

Y'en aurait encore à dire, je ferai un petit journal un de ces 4

Dans ma boîte, depuis que les interfaces graphiques ne sont plus utilisées (en gros depuis le passage à git) il n'y a plus de commits faits n'importe comment.

Comme Git est inutilsable autrement qu'en ligne de commande une limitation devient une feature c'est ça ?

Ca me rappelle les zélotes de SVN qui ne jurent que par l'intégration continue simplement parce que SVN est incapable de gérer plus d'un branche correctement.

Intégration dans Trac
=============
La je crois qu'il n'y a pas trop de pb de ce coté avec les outsiders


Intégration dans eclipse
===============
HGE (pour Hg) est à ma connaisance assez abouti et son dev est maintnat soutenu par CodeBeamer un editeur de bug tracker.
Le plugin pour Bazaar est à chier.

Par contre tu parles de Windows (Visual Studio) et cc'ets un peu ma crainte aves GIT.
Au niveu du CLI rien de consistant.
On a d'un coté msygit en natif et de l'autre une réimplementation en Java JGit avec un CLI balbutiant et un plugin Egit basé dessus.
Qu'est-ce qui se passe quand le format de stockage évolue. Sont-ils compatibles à 100% en attaquant le même dépôt
Hg me parait plus consistant avec un seul backend quelque soit l'OS.
Hg a aussi un "command set" beaucoup plus simple à appréhender.
Enfin, je ne parlerai pas de la possibilité de customiser Git sous Windows (à coup de cygwin c'est quand même un peu gruik)
Avec Hg tu peux ecrire tes plugins et tes hooks en python plutôt que d'appeler des suprocess ou des scripts. J'imagine qu'il doit y avoir une API C à Git mais existe t'elle sous Windows. Peut-être que l'API EGit est suffisante.

L'historique
=========
Ta demande est un peu confuse
A un moment on a l'impression, que c'est l'arbre de version Clearcase (par fichier) qui te manque puis le browsing des sources distant via ton navigateur
et après en local dans Eclipse.
En quoi le fait que le browsing local est un pb ? Tu n'as qu'a updater et en plus c'est beaucoup plus rapide.
Si tu le fais à distance tu passes par ton navigateur (avec HG tu as d'ailleurs un mini serveur web qui te permet de browser n'importe quel clone)
Il existe peut-être des plugins qui pemettent de browser dans Eclipse un repository distant mas je ne vois pas l'intérêt. (sauf peut-être ne pas être polluer par les branches locales de Git)

Je vais essayer de répondre en partie à ton cahier des charges qui est plutôt garni.

J'ajouterai 2 outsiders que sont Bazaar et Mercurial et j'ignorerai CVS

Ton workflow:

- on commit régulièrement dans la mainline pour les dev en cours
- si une feature est impactante, on créé une branche que l'on maintient à jour à coup de merge
- on merge sur la mainline quand le dev est fini.
- on créé une branche de release quand le code est pret à être livré.
- les bug fix sont appliqués sur la branche de release et sur la mainline.

Tous les VCS supportent ton workflow à priori mais SVN a quelques limitations.
Il ne supporte pas les merges cycliques comme ca:
B T
|<-|
|->|
|<-|
|->|
Dans ton cas tu ne merges que dans un sens (release vers mailine) et au pire une fois dan l'autre sens pour réintegrer un bugfix:
|<-|
|<-|
|<-|
|->|
Avec SVN le dernier merge se fait avec l'option réintégrate et la branche doit être killée.
Autre limitation, si tu branche une fois tu ne dois JAMAIS refaire un cp entre les 2 branches depuis un sous-répertoire sous peine de faire mumuse avec les mergeinfo
Enfin bon courage pour suivre un changeset losrque tu a fait un mv :
http://linuxfr.org/comments/1204996.html#1204996

Centralisé
======
A vérifier mais hormis les VCS purement centralisés, le seul DVCS qui supporte ce mode est Bazaar
Par centralisé, j'entends le fait de pouvoir commiter directement dans la branche centrale sur un serveur et si une version concurrente sur cette branche a été commitée, tu en es empêché jusqu'à ce que tu résolves le conflit et que tu retentes ta chance (schema de concurrence optimiste)

Pour les autres (Hg et Git) c'est un peu différent mais il faut comprendre qu'on y arrive très bien sinon il ne serait pas possible de faire de l'intégration continue avec les DVCS.
Le principe est qu'on travaille dans sa propre branche et que par defaut le commit distant est séparé en 2 étapes: 1 commit local + 1 push.
Il est toujours possible d'enchaîner ces 2 étapes en une même transaction et c'est au niveau du serveur (au moment du push) qu'est géré le fait d'accepter ou non le changeset car il n'y pas d'édition concurrente.
Avec Git, on a des vraies branches, le push est refusé si le changement que tu commites n'est pas une feuille (l'ancêtre de ton changement a déjà un autre fils) auquel cas tu dois resoudre le conflit (equivalnt du svn resolve) dans ta branche et retenter.
Avec Hg c'est un peu comme monotone. Les branches ne sont qu'une commodité et un noeud peut avoir plusieurs fils sans pb.
Par défaut, tu peux toujours commiter ou pusher (à vérifier) même si tu as plusieurs heads. Tu as une commande qui détecte le fait que tu as plusieurs
Si tu veux bloquer, il faut installer un hook sur le serveur (je crois).

Ce qu'il faut retenir c'est que le commit local est quand même un avantage lorsque tu es déconnecté et que tu veux par exemple prendre en charge plusieurs bugs request à la suite et les commiter séparément (merge par la suite) et c'est aussi transparent qu'un VCS centralisé si tu associes commit+push en une seule commande.

En revanche ce que ne permettent pas les DVCS c'est le lock pessimiste (le checkout reserved ala Clearcase puisque tu connais)
Ceci peut parfois s'avérer utile pour les utilisateurs qui ont des besoins très limité ou lorsque les fichiers traités sont inadaptés pour les merges. (modèles UML fragmentés dans Eclipse par exemple)
Avec SVN, tu t'en sors en placant les fichiers en lecture seule et avec une propertie svn:needs-lock.

Bon je poursuis dans un autre post.

annonce que son entreprise se résigne à faire le boulot nécessaire pour implémenter les fonctionnalités attendues depuis trop longtemps par les utilisateurs (notamment, améliorer le système de fusion)


http://subversion.apache.org/roadmap.html


Q1 2011 Branch 1.7.x 1.7.0 feature-complete
...
Q1 2012 Release 1.8.0 repository-dictated config; tree conflicts improvements; rename tracking;


rename tracking issue
=>
Sous Apache
http://subversion.tigris.org/issues/show_bug.cgi?id=3631
=> rename issue tracking ala SVN =>
Sous Tigris
http://subversion.tigris.org/issues/show_bug.cgi?id=898

Opened: Wed Sep 11 01:42:00 -0800 2002
...
"Absolutely must" ? This sounds like a feature which can be postponed
until after 1.0.

...

------- Additional comments from Peter N. Lundblad Fri Sep 23 04:33:46 -0800 2005 -------

Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
renames branch, it won't be merged before 1.3.

...
------- Additional comments from Peter N. Lundblad Tue May 2 01:14:02 -0800 2006 -------

The 1.4 branching point is approaching and this is not happening before that,
so move into 1.5-consider.

...
------- Additional comments from Erik Huelsmann Wed Apr 4 08:50:16 -0800 2007 -------

With resources fully concentrated on Merge Tracking, I don't think having this
in 1.5 is viable. Moving to 1.6-consider.

....

------- Additional comments from Hyrum K. Wright Tue Mar 10 06:45:10 -0800 2009 -------

Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
move to 1.8-consider.



and now ? reported à la 1.?.? nom de code "Saint Glin Glin"

rename tracking kezako ?

1- créer un fichier foo.c sur le tronc et commiter
2- brancher
3- renommer foo.c en baz.c dans la branche.et commiter
4- editer foo.c dans trunk et merger dans la branche
....
Tadaaaa

compute ~~~~ SVN,~~~~ Failed ~~~~Git~~~~ Success ~~~~ Hg ~~~~ Success~~~~
Enjoy !!!!

Imaginez la joie de ceux qui se lancent dans un refactoring sous eclipse en renommant des classes ou des packages en utilisant plusieurs branches,(obligé de le rélancer dans tous les projets) vous comprendrez pourquoi l'intégration continue a de beaux jours devant elle avec un outil qui est incapable de merger correctement.

trivial donc inutile de le préciser !
CQFD

Tu peux aussi être sous Haiku, BSD, ...et tous ces malheureux oubliés qui représentent un potentiel de croissance phénoménal .... et surtout qui ne doivent certainement pas savoir comment procéder.

Je crois que ta note est parfaitement méritée.

Caractère informatif à peu près nul, doublé d'une mauvaise foi à faire passer les politicards pour des lapins de garenne => troll detected.

Dommage pour toi, il est tellement à découvert que tu n'égaleras pas ce bon vieux Etienne.

T'as raison être débutant et sous Linux ca existe, bien sûr (hypocrisie detected ?)

En plus prendre des parts de marché à ces mêmes linuxiens pas réputé pour être sectaires, tout le monde y croit.


"Bon sens commercial"
pour ... 5% de personnes versatiles qui occupent ... 1 % du parc installé... comment dire

Quand au respect, on ne parlera pas des distribs concurrentes mais je me doute qu'elles doivent bien mettre en avant les concurrents.

M'est avis que la mauvaise foi n'a pas de limite alors faut pas s'géner hein.
Et dire qu'on est que Lundi

On va quand même pas exiger des mandriviens qu'ils apprennent la grammaire ? Ils ont déjà assez de taf à configurer leur bouzin pour que leur clavier soit opérationnel

Tu es retourné sous Mandriva ?

Sur ce, je m'en vais retourner à une "2010.1 one".

Bye bye ubunteros !! J'ai bien tenu 2 minutes... j'aurais tenté...


Ca explique sans doute pourquoi ton clavier s'est blo...
et qu'on ne connaitra pas la fin de tes aventures captivantes.

Moi aussi je vais donner mon petit exemple:

Envie d'installer ImDB.py sans me prendre la tête avec un simple exe àlà Windows et là c'est le drame: il existe pas pour la 2.7 de python

Obligé d'en passer par un setup.py qui me crache à la gueule parce qu'il faut se taper l'install de lib natives.
Bilan: 1h de perdue

Je ferai pas l'offense aux linuxiens de leur demander combien ca leur prend pour faire de même sous leur distrib.

Mais tu as raison même pour les devs W$ c'est plus simple.

"être dans le milieu, connaitre"?


Toi qui est vieux de la vieille en W$, jure moi que tu n'as jamais eu à aller récupérer une dll au fin fond du net et à la recopier dans ton path pour qu'un de ces jolis petits softs fonctionne.

Jure moi que tu n'a pas pesté parce que celui-là te demandait de passer à la dernière version de dotnet et tu te retrouves en cascade à installe le dernier service pack qui te récupère les maj de IE dont tu n'as rien à carrer, que tu te retrouves à passer une heure pour tester ce truc alors que ca se fait soi-disant en un claquement de doigts.

Bizarrement ca compte pas là, faut pas être expert, hein.

Et puis

Tu trouveras toujours des contre-exemples, toujours...

N'oublie pas de t'appliquer cette jolie remarque à toi-même


Mais au final, globalement, il y a des gens qui préfèrent rester sous Windows parce que c'est plus simple de manière générale.

Ou ai-je prétendu le contraire ? Bien souvent je m'associe à toi pour ce constat.

Quand à savoir s'il y a un rapport de cause à effet avec le modèle proprio, ...

Mais là tu tentes de noyer le poisson.
Il n'en reste pas moins que ton argument massue "Avec Windows ca marche" est caduque.

Oui à 99%: ils pourront contourner avec la ligne de commande comme sous ce bon vieux Tux.
Tu iras expliquer ça à nos utilisateurs.

Remarque, ca devrait nous faciliter le boulot pour les convaincre de d'adopter une nouvelle solution... libre cette fois.

Et pour préciser le contexte avant que tu ne me sortes que c'est un logiciel de niche (tu réponds pas à Nicolas d'ailleurs sur les exemples qui te defrisent avec Linux)

Pour le mien, je dirais qu'il est (était) mainstream dans la gestion de conf, et que son éditeur est un schtroumpf géant.
Si on avait les sources, on pourrait s'en occuper nous-même, mais voilà il vaut mieux qu'on continue de payer pour qu'ils peaufinent son successeur et tentent de nous l'imposer et continuent à nous éconduire poliment.

Il y a bien une compatibilité possible du 32-bit sur du 64-bit,
mais pareil ça marche pas partout (il suffit de voir les gens pleurer car un package n'est que 32-bit et donc que ça marche pas. Sous Windows et Mac, ça marche).

D'ailleurs voici un bel exemple.
Nous utilisons un logiciel 32 bits qui n'a pas été porté en 64 et que ne le sera pas (moi qui croyait que quand on crachait au bassinet pour du proprio on était les rois du monde).
Alors voilà ce beau logiciel et ben il a un zoli menu dans l'explorateur Windows et en 64, il ne l'a plus.

Alors évidemment on se retourne vers notre gentil éditeur qui nous annonce fièrement que c'est normal et que c'est la fôte aux zôtres
qui veulent pas mettre la win32 dans leur Seven, ces nazes (Comme si c'était dur de réécrire un menu en 64)
http://support.microsoft.com/kb/895561



1- belle démonstration de portabilité 32, 64
2- si les communautés ne savent pas s'entendre comment éviter pour que 2 boîtes proprio ne se refilent la patate chaude.
3- Tes belles démonstations de supériorité du modèle proprio, ... euh tu te les gardes merci.

Et on les démasque facilement ! Ils écrivent sur les forums et autres réseaux sociaux avec une orthographe déplorable.

C'est pas "Gode Bless Apple" plutôt ?

J'ai vu passer une petite analyse d'un compère DLFPien sur Planet Libre et j'aimerais vous la partager:

http://www.planet-libre.org/index.php#post8378

Je rejoins son opinion à plein de niveaux:
supériorité technique de Qt sur Gtk, incohérence des bureaux mainstream lié au modèle "bazar", MS parle de Qt pas de KDE, ...

au hasard Solaris 10

Encore plus fort:

DLFP en RoR

Combien chausse une fillette ?