Discussion :

[LapinGarou]

Cela s'appelle la sélection naturelle: Il n'a aucune jugeote, et se croit au pays des bisounours, donc ne mérite pas de réussir dans ce domaine pour le bien de ses clients, et il fait cela très bien tout seul

[Amethyste]

j'ai relu deux fois cet article.
C'est moi ou bien il s'agit manifestement d'une traduction automatique avec un chemin du style:
anglais => klingon => latin => allemand => arabe => japonais => russe => français

Y a des phrases qui n'ont simplement pas de sens

[petitours]

faire joujou sur de la prod et ne pas avoir de sauvegarde c'est doublement étonnant...
Plus étonnant encore c'est de se venter (et gueuler contre autrui) après en avoir fait une pareil !

Les sauvegardes ça reste un sujet complexe ; les outils de gestion de version promettent pleins de choses, le cloud aussi mais ça n'en reste pas moins des outils capables de tuer les données donc insuffisants pour de la sauvegarde. Il sont capables de part leurs fonctionnalités et de part le fait qu'il y a des gens et des infrastructures qui gèrent tout ça hors de notre contrôle => La sauvegarde locale reste indispensable.

La vérification d’intégrité des sauvegardes est encore plus indispensable ; les fichiers sont ils bien là ? seins ? la totalité des données est elle bien prise en compte par la sauvegarde?
Après il y a les vols et autres incendie qui imposent de dupliquer les sauvegardes sur plusieurs sites.
Il y a une dizaine d'année je me suis fait piquer ma machine et le disque dur de sauvegarde qui était rangé la pièce à coté ; très fier et soulagé je suis allé chercher la sauvegarde distante à 200km de là et là craboum, ils manquait pleins de fichiers, le transfert se faisait mal depuis des lustres !

Pour les sauvegardes il n'y a pas que de bons outils je pense il y a aussi un vrai réflexion "sécurité" à avoir ; pas besoin d'y passer 50h de boulot mais il faut se poser pour y réfléchir.

[JakoJako]

Entièrement d'accord avec abbe2017 !!

En règle générale, avant de commiter / pusher / puller avec GIT, je commence par faire une copie du répertoire. Voire le zipper et le recopier ailleurs ! GIT, c'est pas pour les débutants - et même avec de l'expérience des outils de versionning (SCCS, CVS, SVN...) j'ai toujours du mal à bien comprendre ce que fait GIT - a fortiori quand son fonctionnement est masqué par un IDE...

[petitours]

Entièrement d'accord avec abbe2017 !!

En règle générale, avant de commiter / pusher / puller avec GIT, je commence par faire une copie du répertoire. Voire le zipper et le recopier ailleurs ! GIT, c'est pas pour les débutants - et même avec de l'expérience des outils de versioning (SCCS, CVS, SVN...) j'ai toujours du mal à bien comprendre ce que fait GIT - a fortiori quand son fonctionnement est masqué par un IDE...

En espérant que la réponse sera suffisamment simple pour ne pas partir en hors sujet : quel est l’intérêt d'utiliser Git alors ? intérêt qui est peut être très différent d'un développeur à un autre, ne serait ce que de part la taille de l'équipe ?? (il n'y a pas du tout d'ironie dans ma question ; je me la pose vraiment, contraint entre le besoin de faire du versioning et mon incapacité depuis des années à comprendre le fonctionnement des outils en question)

Merci

[LSMetag]

En espérant que la réponse sera suffisamment simple pour ne pas partir en hors sujet : quel est l’intérêt d'utiliser Git alors ? intérêt qui est peut être très différent d'un développeur à un autre, ne serait ce que de part la taille de l'équipe ?? (il n'y a pas du tout d'ironie dans ma question ; je me la pose vraiment, contraint entre le besoin de faire du versioning et mon incapacité depuis des années à comprendre le fonctionnement des outils en question)

Merci

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

[LSMetag]

Je viens de me poser une question :

Comment a-t-il fait pour tout perdre ? Son dépôt local et son dépôt global ? Il n'aurait pas fait un clone d'un dépôt vide sur son dossier de solution non versionnée par hasard ?

[petitours]

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

Merci, ça m'a redonné motivation pour me replonger dans ce dur monde du versioning. Je suis à l'age de pierre sur ce sujet
ou un boulet qui n'a jamais réussi a y comprendre quelquechose ?
ou un vieux .on froussard qui sais pas profiter des outils modernes
à moins que ce soit de la faute du stagiaire...

[TJ1985]

Merci, ça m'a redonné motivation pour me replonger dans ce dur monde du versioning. Je suis à l'age de pierre sur ce sujet
ou un boulet qui n'a jamais réussi a y comprendre quelquechose ?
ou un vieux .on froussard qui sais pas profiter des outils modernes
à moins que ce soit de la faute du stagiaire...

Vas-y tranquillement, ça vaut vraiment la peine de consacrer quelques heures pour bien maîtriser le sujet. Git est remarquable d'efficacité et de simplicité. J'ai passé avant par CMS, Visual Source Safe et un prédécesseur de Git dont le nom m'échappe. Je n'ai jamais pu envisager un développement sans contrôle de source, c'est une aide inappréciable qui te décharge completement de toute une partie administrative dont on n'a finalement que faire. N'hésite pas si tu as un peu de matos à te faire ton propre serveur, au moins pour jouer. C'est vraiment simple quand on y va tranquillement. Au début j'ai buté sur la séquence commit-push, qui ne m'était pas familière, mais @petitours t'a parfaitement expliqué le truc.

[Marco46]

Le but de GIT est d'offrir un versioning décentralisé.
Le principe est qu'au lieu de faire des commit et des get sur un même repository, chacun va cloner l'intégralité du dépôt sur sa machine. Et diviser ensuite chaque tâche en branches distinctes, pour qu'en gros il n'y ait pas de conflits au moment du merge. Ensuite, chacun peut développer dans son coin, en ayant pas ou peu besoin du réseau. Quand on commit, on ne le fait que sur son dépôt local. Il faut faire un "push" manuellement ensuite, et normalement GIT s'occupe de faire un merge correct sur le dépôt distant.

Donc ça permet de soulager le réseau, de bien segmenter les morceaux de l'appli, surtout pour les grosses équipes, et aussi de faire des forks.

Vala.

La gestion des branches il y a plusieurs stratégies possibles. Les conflits au moment des merge ça dépend des stratégies et de leur compréhension et mise en oeuvre par les devs.

GIT ne fait pas que gérer le versioning, il permet également de gérer les déploiements ce qui est absolument formidable. GIT étant décentralisé, il sait communiquer via plusieurs protocoles d'un repo git à un autre. D'où l'usage massif par les devops.

Dans les grandes différences fondamentales il y a le fait que les commits étant créés en local, ils restent privés tant que le développeur n'a pas choisi de les publier. Cela crée une différence gigantesque sur ce qu'est l'historique d'un code source géré avec un VCS centralisé et un VCS décentralisé. Dans un VCS centralisé, l'historique des commits est plus proche d'un log des actions des développeurs, alors que dans un VCS décentralisé, comme les développeurs choisissent quand ils publient ils peuvent remodeler leurs commits avant de publier pour leur donner du sens, et du coup l'historique des commits à réellement du sens, ce n'est plus un simple log idiot.

C'est une notion fondamentale qui a de très nombreuses implications et c'est souvent ça qui est mal compris par les gens qui viennent de SVN.

Si vous avez des questions sur git je serai ravi d'y répondre dans la section git du forum qui est je trouve étonnamment assez peu active.

[LSMetag]

Vala.

La gestion des branches il y a plusieurs stratégies possibles. Les conflits au moment des merge ça dépend des stratégies et de leur compréhension et mise en oeuvre par les devs.

GIT ne fait pas que gérer le versioning, il permet également de gérer les déploiements ce qui est absolument formidable. GIT étant décentralisé, il sait communiquer via plusieurs protocoles d'un repo git à un autre. D'où l'usage massif par les devops.

Dans les grandes différences fondamentales il y a le fait que les commits étant créés en local, ils restent privés tant que le développeur n'a pas choisi de les publier. Cela crée une différence gigantesque sur ce qu'est l'historique d'un code source géré avec un VCS centralisé et un VCS décentralisé. Dans un VCS centralisé, l'historique des commits est plus proche d'un log des actions des développeurs, alors que dans un VCS décentralisé, comme les développeurs choisissent quand ils publient ils peuvent remodeler leurs commits avant de publier pour leur donner du sens, et du coup l'historique des commits à réellement du sens, ce n'est plus un simple log idiot.

C'est une notion fondamentale qui a de très nombreuses implications et c'est souvent ça qui est mal compris par les gens qui viennent de SVN.

Si vous avez des questions sur git je serai ravi d'y répondre dans la section git du forum qui est je trouve étonnamment assez peu active.

Merci pour les précisions. Je suis relativement débutant en Git moi aussi, vu qu'au boulôt c'est uniquement TFS. Git c'est pour le perso.

[Yogui]

Plusieurs milliers+ de fichiers en quelques mois, c'est toujours jouable avec certains frameworks, surtout en archivant ledit FW et son cache/tmp dans l'outil SCM

[Lolo78]

Essayez, que ce soit en ligne de commande ou au clic, de créer 5 millions de fichiers même sans rien y mettre dedans, c'est impossible en 3 mois.

Bah, j'ai mis moins d'une minute pour écrire ce script à la ligne de commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 perl -e 'for my $i (1..10) { open my $OUT, ">", "test$i.txt"; print $OUT $i; close $OUT; } '

Résultat:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test2.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test1.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test8.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test7.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test6.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test5.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test4.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test3.txt
-rw-r--r--  1 Laurent         None             1 23 août  20:55 test9.txt
-rw-r--r--  1 Laurent         None             2 23 août  20:55 test10.txt

J'ai volontairement limité le nombre de fichiers à 10, mais il suffit de remplacer 10 par 5000000 dans le script, et j'aurai mes cinq millions de fichiers en quelques minutes (sauf si le file system rend l'âme, bien sûr, je vais donc éviter d'essayer). Et je mets même quelque chose de différent dans chacun de mes fichiers.

[Lolo78]

Et puis bien sûr, autre petit détail, le post d'origine parle de cinq milliers de fichiers, pas de cinq millions.

[TJ1985]

Il est bien énervé, le jeunet. Il n'y a simplement aucune excuse à lui trouver. Trois mois de boulot ça fait du volume. S'il n'a pas été foutu de mettre en place un backup local voire une simple copie locale durant ce temps, tant pis pour lui. Et si il n'a même pas l'élémentaire intelligence de faire un jeu de test quand il essaie un nouveau soft, il a meilleur temps de changer de métier.
On peut éventuellement reprocher à l'informatique actuelle d'avoir trop simplifié les environnements et d'avoir trop complexifié les langages. Mais il faut faire avec et accepter de réfléchir un minimum à ce qu'on fait, toujours.

[petitours]

On peut éventuellement reprocher à l'informatique actuelle d'avoir trop simplifié les environnements et d'avoir trop complexifié les langages.

C'est marrant j'aurais dit l'inverse.
Avant un environnement très simple et code compliqué : Quelques fichiers bien ordonnés dans lesquels on sait exactement ce qu'on fait et où se trouve le code mais des langages super complexes où il faut tout gérer (mémoire déjà...).
Maintenant des environnements usine à gaz avec des SDK, des framework, des librairies, des patchs en veux tu en voila avec des soucis de mise à jour et de compatibilité permanents mais avec des langages ultra puissants qui rendent la programmation ultra simple.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
using patchDeLaMortQuiTueVersion1.3.4.5.22.42revision45 ;
#include AnalyseToutVersion0.4343Patch ;

ErrorConfigurationDeMonEDIQuiChercheDesTrucsDePartout = CalculTrajectoireDeLaLuneEtAfficheBien();
'Fin du programme

Le Meilleur exemple que j'ai vu récemment c'est AndroidStudio : un "truc" fait pour programmer surement très simplement mais qui a demandé 5jours d'installation (et mises à jour) et lance sur ma machine 10 minutes de compilation sur l'exemple fourni "HelloWord" à chaque fois que je touche le moindre bouton même s'il n'y a pas eu de modifications. Et le pire c'est que les développeurs Android trouvent ça normal !

[TJ1985]

C'est marrant j'aurais dit l'inverse.
Avant un environnement très simple et code compliqué : Quelques fichiers bien ordonnés dans lesquels on sait exactement ce qu'on fait et où se trouve le code mais des langages super complexes où il faut tout gérer (mémoire déjà...).
Maintenant des environnements usine à gaz avec des SDK, des framework, des librairies, des patchs en veux tu en voila avec des soucis de mise à jour et de compatibilité permanents mais avec des langages ultra puissants qui rendent la programmation ultra simple.

J'ai bossé sous VMS pendant une quinzaine d'années, puis en mélange Windows + VMS une dizaine. Sous VMS j'ai co-écrit un environnement de développement en DCL, le langage de scripting de VMS, en m'appuyant sur CMS (gestion de sources) et MMS (gestionnaire de build). Ca a fait mal aux pattes, à la tête un peu aussi, mais ce truc fonctionne depuis 25 ans et a pu suivre sans soucis les évolutions d'architecture initiées par DEC puis les repreneurs de VMS. On gérait avec lui des centaines de milliers de fichiers, des centaines d'applications, plus ou moins complexes, le travail coopératif, etc. Mais même après tout ce temps, la plupart des développeurs utilisaient mal les fonctions de gestion de version, pourtant simplissimes.
A contrario, j'ai utilisé des langages spécialisés comme ACMS, DECForms, DCL, SQL etc et COBOL et Pascal comme langages universels. A mon point de vue ils sont verbeux, puisqu'on doit tout leur dire, mais ils sont simples. Tu gères tout, effectivement, et en Pascal tu n'as pas forcément besoin de trop faire attention à la mémoire. Aujourd'hui je me suis mis à Swift et au développement Xcode... Le moins qu'on puisse dire c'est qu'à force de vouloir simplifier les choses les plus simples, c'est devenu fort compliqué ! Tu sais quand utiliser un Optionnal, toi ? Moi, j'hésite encore !

[Asmodan]

[MKuser53]

[DiOxy]

Moi je sauvegarde tout mes raccourcis sur ma disquette dur.
Et pour ne pas être embêter par des messages qui veulent rien dire, du genre "WARNING blabla..." je me connecte toujours en root sur la machine de production de la société, pour installer mes logiciels de torrent et autres pour mes téléchargements. Et j'ai bien écouté l'inconnu qui m'a expliqué comment faire. Même qu'il m'a expliqué comment configurer mon acces ssh et qu'il m'a créé lui-même mon mot de passe. D'ailleurs, c'est bizarre, mais il y a de moins en moins de place sur le serveur, et ses petites lumières derrière arrêtent plus de clignoter. Et les collègue qui connaissent rien, eux, en informatique me disent que leur mule ne marche plus. Qu'est-ce qu'ils font avec un animal dans leurs bureau ? Et puis j'ai pas vu de mule en fait. Je comprend pas.

Ah, c'est bizarre. Je veux me connecter en root et l'ordinateur ne veux pas. Il refuse mon mot de passe.

Ah, c'est bizarre. Un type est arrivé et il a fait un NODIT de mon travail. Et plus il parlait plus mon chef devenais tout rouge. Il devait en dire des conneries...

Dites, au fait, j'ai perdu mon boulot. Vous n'auriez pas la possibilité de me trouver du travail ? Je suis un super administrateur de tout ce qui est informatique. Je maîtrise parfaitement la souris et le clavier azerty. Et les logiciels aussi, comme Zuma, Solitaire, etc...