Reprise du message précédent :
GitLab ou GitHub, avec création de Pull Request et review.
 
On bosse comme ça chez nous depuis un bon moment maintenant, on a fait rentré 4/5 gars depuis 1 an et demi via ce process, c'est nickel

Gerrit c'est moche mais c'est open source et c'est fait exactement pour ça.

BitBucket et Crucible/Fisheye si t'es déjà à fond dans l'écosystème Atlassian c'est pas mal mais c'est cher et lourd.

Moi je pense que l'admin c'est avant tout des rencontres

Le beau geste  

Ah oui mais j'ai pas précisé qu'on utilisait svn et que ça semble impossible de changer à moyen terme  

Donc ça serait des revues en post commit uniquement, je ne suis pas sur que gerrit fasse le taf.

 
Bonjour,
 
Je voudrais des conseils pour un marathon avec mes potes. Ah oui, j'oubliais de préciser : on est tous unijambistes.

Mais mon gars si tu savais le nombre d'entreprises qui ne font même pas de gestion de version sur leur code.

Mais je veux bien entendre tes arguments qui vont convaincre un manager non technique de l'utilité de passer de svn à git.

Parce qu'objectivement, j'ai jamais su trouver les bons arguments concrets.

Le temps gagné lors des merges est non-négligeable.

 
tu risques de déchanter en passant interne    

Carrément.
Par contre, si c'est pas bien structuré, c'est vite la foire. Pire que le plan du métro de Tokyo  

Par contre, avec Git ca peut etre vite le dawa sur les binaires  et les fichiers qui sont pas du .java, .php, ...      
Les merges de SQL, shell ou xml par exemple... (exemple bien merdique : projet SOAP-UI)
Sur mon projet actuel, on est passé de SVN à Git y a 2 ans, à la fois pour les dev et pour l'équipe de recette.  
L'équipe de recette a fait un retour arrière à SVN après 1 an et demi.
 
Coté dev, celui qui maitrise mieux le shell, un dev assez agé, il rage depuis 2 ans contre git

 
Des rencontres à dimensions humaines  

 
ça fait 5 ans que je bosse en alternance
 
edit: Mon mauvais si à la lecture de mon message il y avait un air de superiorité. Pas du tout, j'ai tout à apprendre, même dans 40 ans, on à la chance d'avoir un milieu qui est en mouvement permanent . Mon sentiment plus global c'était que les employés de demain de l'IT sont vache-ment moins passionné qu'avant. Après je dis ça par rapport à mon périmètre oeufs corse

Dis toi que quand les blasés seront encore techos dans 20 ans grâce à une équivalence afpa, tu auras peut être d'autres choses à penser que la guerre Linux - Windows ?

 
Mais je m'en branle complet de la guerre Libre/proprio, chacun fait ce qu'il veut  

Dans le même style que Crucible, et en open source, on utilise Phabricator : https://www.phacility.com/
Compatible SVN, review pre-commit ou audit post-commit, plus task management et chat.
(et CLI aussi).
Equipe de 10 personnes sur 2 sites.

J'ai une question conne. Es-tu dev et as tu déjà bossé en équipe avec un gestionnaire de code source  ?

Déjà fait une réunion avec les 5 dev et/demande leur ce qu'ils estiment être une bonne méthode pour bosser en équipe. Et toi tu apportes ensuite tes points.
Tu mélanges tout ça et tu refait une réunion et vous choisissez en équipe vos choix.

 
Relis ton post d'origine, ça n'a aucun rapport avec ça. Ton post d'origine c'était plus "les admins windows sont des abrutis a cause du clickodrome"
 
Pour le fait que les mecs de demain sont plus cons et moins motivés, je ne pense pas. Je me souviens de ma promo, sur les 15 on était 3~4 valables (bon oui la ça fait bien prétentieux, mais c'est un fait), le reste n'était pas bien sûr de savoir ce qu'ils faisaient la. D'ailleurs la plupart que j'ai revu par la suite n'avaient même pas de boulot rapport avec l'IT.
 
Je pense que c'est une constante qui ne date pas aujourd'hui.

Mais mon gars, j'ai monté ma boite en 2012 et j'ai fait du service en dev soft pour pas mal de clients dans mon coin (jusqu'en 2015 disons avant de pivoter sur autre chose tellement ça m'a gonflé ). Donc la réalité du terrain je la connais. Sans oublier qu'on est centre de formation et qu'on a donné des cours de Git et fait faire la transition à des équipes sur SVN (ou pire, TFS) pour des boîtes parfois bien sclérosées.

Une bonne transition, c'est une transition comprise par tout le monde (via une formation, interne ou externe), des bons exemples qui démontrent le temps gagné (donc les €€€) par rapport à SVN, et de partir sur un workflow précis qui correspond bien à vos besoins.

Après il y a des outils visiblement pour SVN, mais l'intérêt de Git est :

* flexibilité (workflow qui peuvent s'adapter, même si faut réfléchir avant)
* décentralisé (perçu comme moins de risques sur le code)
* nombre d'excellents outils sur le marché (GitHub, GitLab, suite Atlassian si t'aime les trucs lourds, Gerrit, etc.)

J'ai même réussi à faire une transition dans une COGIP de 200k salariés, ça s'est pas fait du jour au lendemain, mais personne n'a souhaité revenir en arrière une fois passé le cap

On a du SVN ici, un truc de 750mo et 73643 fichiers
Ca prend 4hr pour synchro.
 
XaT

 
J'ai uniquement spécifié que le périmètre était ma classe et non pas TOUT les admins windows  

Ils sont pas juste un peu mauvais et réfractaires?

Que ça soit pour du code, SQL, shell, XML, ... git fonctionne pareil.
Les binaires c'est pas fait pour (pas plus que subversion), et ça peut avoir un impact niveau performances, mais niveau workflow y a pas de merge donc je vois pas le soucis?

 
 
Merci pour ta réponse, pour l'instant je ne fais que du dépannage "hotline" j'assure le support des users, avec un peu d'admin : creation de compte, boites mails, gestion des profil sous TSE
 

Ben c'est juste que le mec n'a pas du tout compris comment fonctionne GIT et l'intérêt de GIT par rapport à d'autres solutions.

 
Ouais c'est ce que je me dis mais pour une raison qui m'échappe, les merge semblent plus compliqués qu'avant (j'ai pas connu cette époque, avant je bossais sur un truc sans gestion de version   ), qu'on utilise WinMerge ou P4Merge qui semble être la solution la plus couramment utilisée.  
 

 
Ben ouais mais quand tu bosses sur un app avec IHM, t'as forcément des binaires.  
C'est quoi la solution préco du coup? (flemme de googler)

 
C'est bien ça, globalement, il met une belle énergie à lutter contre le changement ^^.
Après il a quelques critiques sans doute fondées sur la gestion avec GIT des problématiques de line endings Windows/Unix.  
 

Pour la code review, en plus d'outil dédiés (voir ce qui a déjà été cité), sur mon projet actuel on utilise :  
https://github.com/QualInsight/qual [...] smell/wiki  

même pas fondées, il peut activer ou désactiver l'autocrlf s'il le souhaite
il peut même faire du SVN depuis git en utilisant GIT SVN.

Montre lui la puissance des branches locales, et montre lui git stash

J'ai utilisé Perforce pendant ~4 ans et je retoucherai plus jamais ce truc.
Les outils de 2/3-way merge c'est complètement indépendant, tu peux continuer à utiliser WinMerge si tu veux.
Le truc c'est qu'avec git ou un autre DCVS, t'en as rarement besoin donc ça te fait gagner du temps.

Non mais les petits binaires ça pose aucun problème, pas plus qu'avec le reste.
Quand je dis que git est pas fait pour ça, je pense à des ordres de grandeurs où tu devrais héberger sur un blobstore comme s3 et faire un sync quand tu compiles ton projet, donc à partir de ~50Mo.

Par contre l'infrastructure pour GitHub (ou lab ?) est putain de costaud. La dernière fois qu'on avait demandé, le commercial nous avait indiqué qu'il fallait 24Go de ram pour le bousin  

GitLab je pense. Les joies de Ruby on Rails.
 
GitHub on-premises c'est $$$.

GitLab dans des versions récentes ça consomme pas des masses. Avant par contre oui c'était pas top.

 
Gitlab  
 
8Go de ram, tout fraîchement installé, le bouzin commence à swapper.... Rien dessus hein, juste l'install de base sans même acceder à l'interface.
 
Heureusement que y'a un garbage collector    

 
Pour, l'autocrlf, c'est un sujet de débat chez nous. Et pas que. Voir par ex. :  http://stackoverflow.com/questions [...] rue-in-git  
En gros le collègue en question dit qu'on ne devrait jamais forcer dans .gitattrbutes une extension à être considérée comme du texte ou du binaire.  
 
Sinon tu te doutes bien que si ca fait 2 ans qu'on a git, ca fait quasiment autant de temps qu'on fait des braches locales ... Git Stash c'est une mauvaise pratique je trouve. Pourquoi faire ça plutot qu'une branche locale?  

 
J'ai absolument pas de problème avec une VM bien plus petite (2 GiB de RAM)

 
Moi c'était une Ubuntu 16.04 fraîchement installée, et Gitlab fraichement installé depuis leurs dépots.  
 
Encore un truc bien optimisé aux petits oignons .

Moi je fais du DEV sur Raspberry
Si ça passe la dessus, on est large pour un déploiement grandeur nature

Ben branch locale 99% du temps, mais quand tu es sur une branche en cours, que tu testes quelque chose et que quelqu'un vient te dire : hey tu peux faire un test la dessus etc...
Ben tu git-stash ton dev en cours, tu fais mumuse sur son caca et tu feras un git stash apply après

Avec 5 utilisateurs, non?

Environ oui Mais ils disent que ça passe jusqu'à 100 en étant un peu lent Sinon 4GiB peut tenir les 500 sans pb.

https://github.com/gitlabhq/gitlabh [...] .md#memory

edit : sinon GitLab.com c'est gratos hein

Bonjour,
 
Petite question technique : j'ai un routeur 4G auquel on attribue une IP pour dépanner des sites.
Et là j'ai un routeur pour lequel je ne connais pas l'ip qui lui a été attribué ...
 
Une idée pour comment retrouver son ip, genre un logiciel qui peut modifier l'IP et passerelle d'un PC relié en filaire au routeur ?