Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Un développeur efface par erreur trois mois de travail avec Visual Studio Code 1.15
Et exprime sa rage dans un billet de blog virulent

Le , par Stéphane le calme

80PARTAGES

18  0 
Furieux, un développeur est allé exprimer sa rage sur GitHub après avoir supprimé par accident des fichiers équivalents à trois mois de travail de façon définitive.

« Je viens de télécharger VSCode comme alternative et je testais l'option de contrôle source. Voyant comment elle voulait mettre en scène CINQ MILLIERS DE FICHIERS, j'ai cliqué sur “discard” ... ET ELLE A EFFACÉ TOUS MES FICHIERS, TOUS DE FAÇON PERMANENTE !

« COMMENT EST-CE POSSIBLE ? QUELLE EST L’ENFLURE QUI A FAIT QUE CETTE OPTION SUPPRIME DE FAÇON PERMANENTE TOUS LES FICHIERS D’UN PROJET, MÊME PAR ACCIDENT ? JE NE PEUX MÊME PAS LES RETROUVER DANS LA CORBEILLE !!! JE NE PENSAIS PAS QUE CELA SERAIT POSSIBLE SUR WINDOWS !

« J’EMMERDE CET ÉDITEUR AINSI QUE CEUX QUI ONT IMPLÉMENTÉ CETTE OPTION. JE VOUS SOUHAITE LE PIRE.

« DÉSORMAIS, JE VAIS RESTER LOIN, ET DE FAÇON PERMANENTE, DE TOUS LES LOGICIELS DE DÉVELOPPEMENT WINDOWS. ET AUX GÉNIES QUI ONT IMPLÉMENTÉ CETTE OPTION, JE LEUR DIS CECI : ALLEZ-VOUS FAIRE VOIR. »

Manifestement, plusieurs développeurs ne sont pas d’accord avec sa conclusion.

L’un d’eux par exemple attribue son erreur au fait qu’il soit novice, mais regrette que son collègue ne retienne pas la leçon et surtout s’en prenne au mauvais outil :

« La partie triste, c'est qu'il n'a pas appris sa leçon. Le problème n'est évidemment pas au niveau de Visual Studio Code, mais avec Git (ou n'importe quel logiciel de contrôle de version qu'il a essayé). Il semble qu'il ne savait rien sur l'utilisation de Git et a accidentellement vérifié un compte de rechange au lieu d'ajouter ses fichiers sur scène. Dans son billet, il dit qu'il utilise Windows et qu'il est habitué au fait que les choses aillent dans la corbeille, quelque chose qu'un outil Linux comme Git ne va évidemment pas faire. Il s'agit donc d'une inadéquation entre un développeur de logiciel débutant sur Windows qui n'a jamais utilisé Git avant et n’est pas habitué à la logique d'outils Linux comme Git.

« Je suis d'accord avec lui pour dire que Visual Studio Code aurait peut-être pu concevoir son message d'avertissement un peu mieux, pour des personnes comme lui qui n'ont aucune expérience avec Git.

« Parlant maintenant du côté triste : après avoir supprimé accidentellement tous ses fichiers en essayant Git, il ne sera probablement plus tenté d’utiliser à nouveau Git ! Donc, au lieu d'apprendre la leçon qu'il aurait dû apprendre, à savoir toujours utiliser le contrôle de la version sur tout, ce qu'il a appris a été “Git est nocif, ne l'utilisez pas”.

« Bien sûr, il semble aussi qu'il blâme VS Code et ne comprend pas que c'était la faute de Git, mais cela ne fera pas qu'il commence à utiliser Git de sitôt.

« En savoir plus sur le contrôle de la version, en particulier Git, c'est la chose la plus importante qu'un développeur de logiciel peut apprendre le plus tôt possible dans sa carrière. »

Le message original sur GitHub a été supprimé, mais il est toujours possible d’avoir accès au cache.

Source : billet du développeur

Et vous ?

Avez-vous déjà supprimé votre travail en faisant une mauvaise manipulation avec un EDI ? De quel éditeur s'agit-il ? Partagez votre expérience.

Une erreur dans cette actualité ? Signalez-le nous !

Avatar de Issam
Membre confirmé https://www.developpez.com
Le 18/08/2017 à 20:08
Citation Envoyé par Spleeen Voir le message

Moi même j'ai perdu 2-3 fois des centaines de giga (find + rm + regex désastreuse), je peux te dire que ça calme.
et tu es toujours libre dans la nature ?
15  0 
Avatar de abbe2017
Membre confirmé https://www.developpez.com
Le 18/08/2017 à 19:27
règle n°1 du développeur :

des sauvegardes perso en local tu feras même si on te dit que c'est fait en ligne (ou cloud) automatiquement le soir.

règle 2 : ne pas oublier la règle 1
règle 3 : ne pas oublier la règle 2
règle 4 : ne pas oublier la règle 3
12  0 
Avatar de Pongten
Membre expert https://www.developpez.com
Le 18/08/2017 à 22:41
Il y a une erreur de traduction, il parle de 5 thousand files.. soit 5 mille fichiers, pas 5 millions ;-)
11  0 
Avatar de
https://www.developpez.com
Le 19/08/2017 à 0:58
C'est beau tous les messages bien hautains, "c'est un gamin" etc.
C'est bon on a compris qu'il a sérieusement merdé par besoin d'en profiter pour lui recoller des tacles au passage. Vous tirez sur l'ambulance
11  0 
Avatar de tikjdaoui
Membre à l'essai https://www.developpez.com
Le 18/08/2017 à 20:08
Il peut toujours retrouver son travail chez la NSA
10  0 
Avatar de ternel
Expert éminent sénior https://www.developpez.com
Le 18/08/2017 à 19:35
A perdu du travail pour avoir tester une option d'un outil.
Son travail est sa production.

Il a testé un outil sur de la production.
Son chatiment est à mesure de sa faute.

Règle "moins l'infini", celle qui passe avant toute les autres: "Toute production est sacrée."
9  1 
Avatar de caalors
Nouveau membre du Club https://www.developpez.com
Le 18/08/2017 à 21:17
Sélection naturelle !
9  1 
Avatar de Marco46
Modérateur https://www.developpez.com
Le 24/08/2017 à 10:38
Citation Envoyé par LSMetag Voir le message
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.
8  0 
Avatar de AndMax
Membre éclairé https://www.developpez.com
Le 18/08/2017 à 22:55
Troll ou pas, si cet article permet à des gens de se réveiller, ça aura au moins servi à quelque chose. Je suis certain que parmi les lecteurs il y en a qui se disent que leur dernier push commence à dater, ou qu'un vrai backup de plus, ça ne ferait pas de mal. Avec toutes les solutions fiables, automatisées, qui prennent rarement plus de quelques minutes à mettre en place, comment justifier en 2017 l'absence d'un backup ?

Là c'est une erreur de débutant (tester un logiciel sur des fichiers non sauvegardés), mais contre quoi se serait-il énervé si cela avait été une panne de disque dur ou de support flash ?

https://cdn.meme.am/cache/instances/...-kitten-me.jpg
7  0 
Avatar de mister3957
Membre expérimenté https://www.developpez.com
Le 18/08/2017 à 20:21
C'est du fake ça, c'est pas possible autrement.

- Trois mois de travail
- 5 millions de fichiers

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.

- 0 connaissance concernant git
- 0 connaissance concernant les systèmes de backup (bien que dans ce cas apparemment il n'y a pas de faille matériel)
- 0 connaissance.. tout simplement

Mais trois mois de travail et 5 millions de fichiers, et surtout sous Windows.. un vrai pro !
8  2