[quote=“AnA-l, post:16, topic: 56429”][/quote]
P4 est gratuit pour <20 users et <20 workspaces
Sinon congrats pour le 10.000è post
[quote=“Histrion, post:19, topic: 56429”][/quote]
+1 pour Mercurial , question facile à comprendre et à prendre en main , y’a pas mieux
[quote=“Donjohn, post:17, topic: 56429”][/quote]
Ouais, si c’est 3 png pour un site web, pourquoi pas.
La je te parle de 1To d’assets diverses qui représente un historique qui se compte en dizaines de To.
(Et de résultats de compilations qui se comptent en Go par configuration/plateforme)
Sur un projet 20x moins gros, on mettait deja Git a genou. La j’imagine meme pas.
Mais clairement, pour le source, c’est un autre monde, c’est clairement gerable.
[quote=“SkullyFM, post:21, topic: 56429”][/quote]
Yep, mais ca va vite 20 personnes et 20 workspaces.
10 000 ! Ho putain, apero !
[quote=“AnA-l, post:23, topic: 56429”][/quote]
D’ailleurs qu’est ce que Perforce considère comme un “workspace”. C’est un projet ou un ordi ?
[quote=« Donjohn, post:10, topic: 56429 »][/quote]
Ok. Merci pour la piste 
Je connaissais XMLSpy pour gérer des diff/merge XML :
http://www.altova.com/fr/xmlspy/compare-xml.html
Je ne sais pas si de meilleurs outils n’ont pas vu le jour depuis.
[quote=« Histrion, post:26, topic: 56429 »][/quote]
haaa ? Merci
[quote=“SkullyFM, post:24, topic: 56429”][/quote]
C’est une instance d’un dépôt sur une machine (en gros, une version syncé du depot a un endroit)
T’as au moins un dépôt par machine, mais tu peux en avoir plusieurs (la, je suis a 9 par exemple :p)
[quote=« phili_b, post:25, topic: 56429 »][/quote]
ouais enfin l’algo ca peut etre un soft hein, celui linké par Histirion semble bien, s’il a un mode ligne de commande tu peux tout automatiser 
[quote=« Donjohn, post:29, topic: 56429 »][/quote]
Tout à fait C’est ce que je me suis dit en lisant son message en le recoupant avec le tien. Je vais ramener l’intersection de vos suggestions au boulot aux collègues qui gèrent git et l’écosystème qui va autour
smartTree, je kiffe bien, thx, je le trouve plus clair pour les débutants, dans le sens ou il montre plus ce que git fait ou va faire.
SourceTree ou SmartGit ? 
Quand tu parles de débutant, Donjohn, est ce que certains GUI git conviendraient à des graphistes ou intégrateurs ?
En tout cas je n’ai pas essayé les programmes que tu cites, mais je trouve Git GUI vraiment pas ergonomique, git en ligne de commande est plus pratique…mais vite abscon pour les allergiques aux lignes de commande.
Oui enfin gestion des branches on va pas être amis la, par ce que en deploiement continue et sous git tu fais tes branches dans ton coin et il y a qu’une seule branche master, qui part direct en prod des qu’un commit est push sur origin. Avoir une branche dev au lieu d’avoir n branches perso, c’est une hérésie dans ce modele.
mouais… c’est pas trop trop le thread, mais soit je comprends pas ta derniere phrase et dans ce cas, on est ptet d’accord, sinon on l’est pas. Dans mon schema, la branche dev represente en fait la preprod, chaque branche de dev-master represente des developpements au fur et à mesure. Mais quand t’as 3 devs en même temps, il te faut bien une branche de test qui merge tout avant la prod.
On fait un peu pareil sauf que la branche dev n’est jamais mergee dans Master, au lieu de ça on merge chaque branche ticket quand elle est validée. Ça permet de ne pas geler dev en attendant une livraison, et de livrer des tickets même si il y en a un autre qui n’est pas validé, mais ça apporte son lot de problèmes.
[quote=“GloP, post:34, topic: 56429”][/quote]
[quote=“Donjohn, post:35, topic: 56429”][/quote]
GloP doit parler du Flow proposé par Github: https://guides.github.com/introduction/flow/et toi Donjohn, tu utilises Git Flow http://danielkummer.github.io/git-flow-cheatsheet/.
Deux approches différentes.
[quote=“Rabban, post:36, topic: 56429”][/quote]
Je faisais ca avant, sauf que si tu dois merge 2 branches sur la master, avec un Jenkins au cul t’as besoin d’un env pre-prod pour tester avant MEP.
Je mergeais donc mes devs sur la branche preprod et pas dev. puis je mergeais preprod sur dev et prod quand la recette était bonne. Ca marchait bien mais à un moment je me suis rendu compte que la branche dev ne servait à rien, qu’elle était la copie parfaite et fonctionnelle de preprod et que je pouvais me passer de preprod pour utiliser dev uniquement.
Et dans le cas de livraisons d’un feature particuliere, normalement, la branche dev doit être clean et reflete la copie de prod apres livraison. Suffit de merge la branche en cours avec un fork de master pour sortir un patch de master. Ca arrive que trop rarement dans mon cas pour m’embeter avec.
Si chaque commit arrive en prod en quelques minutes apres avoir ete pris par un git push du dev et que ca lance le deploiement en beta/gamme/prod avec les tests idiones a chaque fois, y a pas besoin de branche de preprod. Tu commit sur master, master vas en beta, gamme et prod des que ca touche origin. Si un dev veut faire une feature dans son coin et faire des check ins avant d’avoir fini il peut se creer sa propre branche. En regle generale y a jamais de code ecrit qui ne finit pas en prod dans la semaine (qui peut bien sur rester off par defaut et pas exposee pour le grand public pendant des mois).
Oui, je vois mais on est pas sur les mêmes produits avec la même infrastructure. J’aimerais installer ces process dans ma boite mais je dois bouger un dinosaure donc c’est pas facile tous les jours