Je travaille dans une institution gouvernementale. La technologie utilisée ici et les méthodes de développement de logiciels sont assez démodées.

Ils disposent de beaucoup d'espace de stockage, mais pas d'espace approprié pour conserver et maintenir les applications utilisées pour automatiser la plupart des tâches.

L'institution ne m'autoriserait pas à utiliser un logiciel SCM comme GIT ou SVN.

Quelle serait la meilleure approche pour conserver la qualité du code et pouvoir ajouter de nouvelles fonctionnalités dans les applications ultérieurement?

Comment puis-je me souvenir des modifications que j'ai apportées au code sans le casser?

EDIT: J'ai oublié de mentionner, ils ont des lecteurs réseau pour chacun des ordinateurs et d'une manière ou d'une autre, ces lecteurs réseau font ou sauvegardent des sauvegardes par périodes. Toutefois, si je ne crée pas mon propre plan permettant de sauvegarder mon travail et de pouvoir ajouter de nouvelles fonctionnalités sans rompre le code existant, il n’ya pas de gros avantage par rapport à une solution SCM.

EDIT: Depuis que beaucoup de gens ont suggéré Git portable, je dois ajouter plus d’informations. J'ai essayé d'installer le serveur Visual SVN, mais cela a échoué car je ne dispose pas de privilèges d'administrateur pour l'installation. J'ai également essayé de télécharger un shell Git standard, mais le pare-feu ou les paramètres réseau ne me permettaient pas d'accéder à la page de téléchargement de Git. J'ai même essayé d'envoyer Git sur mon email, qui est Gmail. Google a détecté le fichier exe dans le package et ne m'a pas non plus autorisé à télécharger la version portable de Git sur mon ordinateur de travail. Une autre chose que je dois mentionner, la stratégie réseau appliquée aux ordinateurs de l’établissement ne permet pas d’utiliser des ressources de stockage USB. Vous pouvez utiliser les ports USB pour charger un smartphone ou alimenter certains gadgets tels que de petites enceintes. En outre, comme certaines personnes l'ont mentionné, il existe des ordinateurs sur lesquels même Internet n'est pas autorisé.

Vous pouvez reproduire librement le rôle joué par le contrôle de source avec trois outils simples:

• Logiciel de sauvegarde (Validation / Enregistrement)
• Dossiers (branches)
• Effectuer une fusion de répertoires entre deux répertoires à l'aide d'un outil tel que KDiff3 (Fusion de branches)

Fondamentalement, votre flux de travail devient:

1. Créer un nouveau dossier (nouvelle branche)
2. Copier les fichiers dans le nouveau dossier (nouvelle branche) à partir d'un dossier existant (branche existante)
3. Faites une sauvegarde de ce dossier (finissez de créer la nouvelle branche)
4. Faire du travail
5. Faire une sauvegarde du nouveau dossier (commit)
6. Faire une fusion de répertoire d'un dossier à un autre (fusion)
7. Faire une autre sauvegarde dans l'autre dossier (valider la fusion)

Les systèmes de contrôle de source plus monolithiques, tels que SVN ou TFS, le font pour vous dans les coulisses.

La réalité, c’est comme une compagnie de bus qui dit à ses conducteurs qu’ils ne peuvent pas conduire avec des batteries avec une batterie, les obligeant à pousser l’autobus en bas de la colline puis à déclencher l’embrayage pour démarrer l’autobus ... c’est terrible et indique que la direction actuelle ne sait rien de la gestion d’un garage d’autobus. Mes condoléances.

Mais au moins, vous pouvez démarrer le bus.

Bien que le consensus soit certainement de ne pas travailler pour cette entreprise, je ne crois pas que cela réponde vraiment à votre question.

Vous ne pouvez pas vraiment remplacer SCM .

Vous pourriez ne pas avoir besoin des cloches et des sifflets habituels d'un système complet. Par exemple, l'entreprise peut refuser une demande de serveur, mais autoriser l'utilisation d'un SCM local. Ils peuvent ne pas aimer git, mais autoriser la subversion (ou un autre système de gestion de versions).

Il y a bien sûr une question: qu'utilisent vos collègues ou les anciens travailleurs? Si vous êtes le premier développeur de logiciel dont ils disposent, alors il est temps de faire tout son possible pour obtenir les ressources dont vous avez besoin.

En fin de compte, si votre entreprise ne respecte pas votre rôle et votre expérience et ne vous permet pas les outils dont vous avez besoin, vous vous exposerez à des problèmes encore plus graves (et plus stressants) qu'un manque de contrôle de la source.

Fondamentalement, il existe un problème de gestion (votre organisation ne comprend pas les bases du processus de développement logiciel , par exemple le modèle V ), qui se résume en une incapacité apparente à utiliser un flux de travail, une méthodologie et des outils minimaux. Ceci est courant (lisez à propos du principe de Peter ).

^{BTW, je suppose que le récent incident ferroviaire SNCF à Paris fin 2017 a une cause similaire (absence totale de culture logicielle à un niveau de gestion élevé, d'où le blocage d'une grande gare parisienne pendant plus d'une journée; bien sûr, il Les équipes informatiques de la SNCF, mais elles ne sont pas consultées sur les décisions majeures). Je peux nommer plusieurs industries européennes totalement dépourvues de culture du logiciel et je suis sûr de pouvoir trouver des choses similaires, même aux États-Unis.}

Le problème principal est: travaillez-vous seul sur votre base de code ou travaillez-vous avec des collègues?

Si vous travaillez seul, vous pouvez utiliser git localement sur votre ordinateur et sauvegarder votre code (et probablement même votre .gitréférentiel) périodiquement (sur cet espace de stockage externe). Assurez-vous de ne jamais perdre plus d'une demi-journée de travail (alors sauvegardez vos données de manière régulière et fiable).

^{(Je suppose que vous connaissez au moins les deux gitet svnet que vous connaissez la supériorité technique de git; si vous n'êtes même pas autorisé à installer un outil comme gitsur votre ordinateur de travail, vous devez avoir une conversation sérieuse avec votre patron à ce sujet: vous avez besoin la capacité et l'autorisation d'installer des outils open source externes (et cela va de pair avec votre responsabilité de choisir, configurer et installer ces outils judicieusement et avec soin , sans vulnérabilités connues )}

Si vous travaillez avec plusieurs collègues (moins d'une douzaine, je suppose), vous devez les convaincre tous d' utiliser un système de contrôle de version, et vous devrez probablement en parler à votre supérieur immédiat (et commun). Il pourrait (probablement) décider (ou simplement accepter implicitement) qu'une machine (peut-être même un vieux bureau, peut-être même le vôtre) est utilisée comme serveur git. Vous devez absolument configurer ce serveur pour que le référentiel git soit sauvegardé au moins toutes les heures. vous ne pouvez pas vous permettre (et vous devez parler à votre patron) de perdre plus d'une heure de travail de votre équipe.

^{BTW, j'adore Linux, et je recommanderais d'installer Linux sur la machine faisant office de gitserveur; puis installer gitet configurer des sauvegardes périodiques (avec quelques crontabtravaux) est très facile; remarquez qu'un gitserveur peut exécuter Linux avec les clients Windows qui l'utilisent. Je vous suggérerais même de basculer votre machine de développement vers Linux si vous le pouvez. C'est "moins cher" et beaucoup plus convivial pour les développeurs}

Mais vous devez utiliser un SCM. Vous pouvez poser à votre patron une question différente: votre équipe doit-elle utiliser un modèle de gestion de chaîne existant ou doit-elle réinventer la roue et créer votre propre système de gestion de chaîne? Les patrons sont généralement contre l’idée de réinventer la roue. Si vous êtes autorisé à réinventer la roue, dites à votre patron que c'est un emploi à plein temps pendant au moins un an (cela fera probablement pleurer votre patron, puis acceptera le moyen évident) et amusez-vous à créer votre propre SCM. Dans ce cas peu probable, assurez-vous d'étudier les systèmes SCM existants et demandez à ce que votre système soit un logiciel gratuit (à utiliser et à améliorer par d'autres équipes).

Vous devrez peut-être préparer (pendant plusieurs jours) une argumentation précise et spécifique sur la nécessité d’un SMC : d’abord pour vos collègues, puis pour votre supérieur hiérarchique. Assurez-vous également de suggérer des solutions concrètes (par exemple, exécuter un serveur git sur un ordinateur de bureau ou un "ancien" serveur, et le sauvegarder toutes les heures dans le cadre d'un crontabtravail).

N'installez aucun logiciel (de l'extérieur, même open-source) sur votre ordinateur de travail sans autorisation (dans la plupart des pays, en particulier pour les tâches informatiques sensibles effectuées par l'État, installer un logiciel sans autorisation est un crime, et vous risquez de perdre votre ordinateur. travail ou aller en prison si vous faites cela ... alors assurez-vous d’être autorisé à le faire, couvrez peut-être votre cul en demandant une permission par écrit, ou au moins par courrier électronique).

^{(Soit vous devez demander au cas par cas, soit vous devez obtenir la confiance de votre organisation pour pouvoir installer n'importe quel logiciel juridique - principalement des logiciels open source ou gratuits - sur votre ordinateur de travail).}

PS Comment construire techniquement, configurer, installer puis utilisergit (à partir de son code source de logiciel libre) - ou la plupart des autres logiciels libres VCS - sur une machine (même sans permission de l'administrateur) est une question très différente (à poser ailleurs). Et il est possible d'installer puis d'utiliser gitsans aucune permission d'administrateur, à condition de disposer de suffisamment de ressources (temps, espace disque, compilateur C, etc.) pour cela.

J'ai essayé d'installer le serveur Visual SVN, mais cela a échoué car je ne dispose pas de privilèges d'administrateur pour l'installation.

Ceci est résoluble par une configuration spécifique et la compilation de votre gitou svndu logiciel libre code source gitou juste un SubVersion -non package- binaire (et aussi le code source de dépendances ); comment faire sur le plan technique qui est une autre question (mais ces questions techniques devraient aller à un autre endroit). Bien sûr, vous devriez demander la permission (à votre patron) de compiler le code source gitavant de le faire. Il vous indiquera, ou vous discuterez avec lui, des détails pratiques (s'il accepte une telle solution) concernant le transfert de ce code source de l'extérieur sur votre ordinateur de travail.

La première chose que je ferais, c’est d’identifier précisément ce à quoi l’organisme gouvernemental (probablement le département informatique) s’oppose. S'ils disposent d'espace de stockage, mais ne disposent d'aucun moyen d'héberger des ordinateurs virtuels pour des serveurs, le problème peut être que le service informatique dit non au serveur SVN ou au serveur GIT , ce qui constitue une grande différence. Si le problème est le pays d'origine - autrement dit, nous ne faisons pas confiance aux outils créés par des entités étrangères - le problème est différent.

Vous pouvez exécuter GIT complètement dans le système de fichiers, ce que j'ai déjà fait sur des projets infantiles avant de pouvoir faire quoi que ce soit avec eux. GIT ne nécessite pas non plus de privilèges d’administration pour l’installation.

Si vous ne pouvez absolument pas utiliser Git pour quelque raison que ce soit, quelques options s'offrent à vous:

• Éduquer: en n'autorisant pas le contrôle de version, ils introduisent un risque important. Vous devez être en mesure de vous protéger des changements qui s'avèrent plus problématiques. Vous devez avoir la possibilité d'économiser du temps et de l'argent au gouvernement, et c'est ce que fait SCM. Vous devez pouvoir expliquer clairement comment. Vous devez également probablement faire une analyse des solutions de rechange pour vraiment faire comprendre le problème.
  • Une alternative serait hébergé Git
  • Un autre système de fichiers Git
  • Choisissez au moins un, mais pas plus de deux autres outils SCM alternatifs
  • et enfin, comment travailler sans contrôle de version
• Go développement des années 70 ère: Il y a une raison patchet diffont si longtemps (80). Ce sont les technologies habilitantes qui ont rendu le contrôle de version possible.

À quoi ressemble le développement de l'ère des années 70? Ce n'est pas joli, mais c'est comme ça qu'on a commencé. Les applications étaient beaucoup plus petites. Ils avaient essentiellement des choses communes:

• Il y avait le concept de l' étalon-or . C'était le code source principal qui avait des fonctionnalités complètes.
• Il y avait une équipe de gestion de la configuration (CM). Leur responsabilité était d’obtenir correctement les changements du développement dans l’étalon or. C'est là que vous devez patchet diffremplacer l'équipe.
• Vous avez travaillé à partir d'une copie locale du code source. Vous terminez une fonctionnalité dans son intégralité et la soumettez à l'équipe de gestion de contenu pour qu'elle l'intègre. Il existe généralement un document d'accompagnement pour la création de nouveaux fichiers, la suppression de fichiers obsolètes, etc.
• Ensuite, vous corrigez les erreurs du processus d'intégration.
• Avant de pouvoir proposer une autre fonctionnalité ou correction de bogue, vous recevez une nouvelle copie de la norme standard.

Essentiellement, il s’agit d’un processus sujet aux erreurs et susceptible de mal tourner. L'idée de "branchement" est facile à mettre en œuvre, mais c'est un cauchemar à gérer. Le problème majeur est que, lorsque vous avez trop d'exemplaires du code source, il est difficile de comprendre quelle est la base de référence correcte pour la production. Pour des raisons pratiques, vous devez devenir un seul thread.

C’est ce que vous devez inclure dans votre analyse des alternatives.

Compte tenu des contraintes que vous mentionnez dans les commentaires (par exemple: impossible d'accéder à la page de téléchargement de Git, à la plate-forme Windows et à Visual Studio 2005), je vois deux options que j'ai déjà utilisées dans une situation similaire:

1. Utilisez Visual SourceSafe comme le suggère Emerson dans un commentaire. J'ai travaillé avec une équipe utilisant VS 2005 il y a quelques années, alors que la plupart des autres entreprises utilisaient le contrôle de version standard sous Linux / Unix et utilisaient Visual SourceSafe pour leur CM. C'est assez démodé à ce stade, mais mieux que rien.
2. En parlant de mieux que rien, je suis moi-même dans le même sac. Si vous ne pouvez même pas utiliser VSS (peut-être que le plug-in n'est pas installé?), Et puisque vous dites qu'il y a beaucoup d'espace de stockage disponible, j'espère que vous pourrez en utiliser une partie. J'ai mis en place un protocole de contrôle de version manuel basé sur des fichiers. À la fin de chaque journée de travail, je copiais la base de mon code dans un nouveau répertoire horodaté. Si je devais revenir à un travail précédent (ou revenir en arrière), je regarderais dans des répertoires antérieurs datés pour trouver le changement dont j'avais besoin. Étant donné que Visual Studio est disponible, dans quelques heures, vous pourriez probablement utiliser VS 2005 pour écrire un outil simple vous permettant d’automatiser la création de répertoires et la copie de fichiers.

Ils ont des tonnes d'espace de stockage

Êtes-vous autorisé à l'utiliser à votre décision?

Si c'est le cas, vous pouvez créer un référentiel distant du système de fichiers, ce qui est mieux que rien. L'inconvénient est que la compression devient lente pendant la croissance du projet car il gitfaut télécharger tout le référentiel pour rechercher les modifications ...

Jusqu'à présent, les ordinateurs se comportent comme des utilisateurs ordinaires, m'interdisant d'installer des logiciels tiers.

gitvient également comme une application portable afin que vous puissiez l'installer dans votre chemin $ HOME ou% USERPROFILE%.

En conclusion: je ne les laisserais pas m'interdire d'utiliser un SCM ¹ . Je l'utiliserais "en privé". Après tout, personne ne peut dire si votre code a été développé avec ou sans vérification quelque part ...

¹ ) quand j'ai commencé à utiliser gitil y a quelques années, mon client préférait un autre SCM qui était plutôt lent et peu fiable (ce qui est en quelque sorte un NOGO pour un SCM (o;). J'ai utilisé git"en privé" par-dessus l'autre SCM. avec une télécommande "basée sur un fichier" sur un partage réseau et ne s’enregistrant dans leur GDS qu'après la publication d’une nouvelle version du produit.

Votre environnement

Tout d’abord, je ne serais pas si pessimiste que le montrent de nombreux commentaires et réponses. Oui, nous sommes à l'âge de pierre, mais les circonstances sont bien pires. Si votre environnement de travail global (collègues, lieu, salaire, travail de programmation intéressant, etc.) est correct et à votre goût, ne vous gênez pas. En ce qui concerne l'informatique, c'est ce que c'est. Cela ne se produit pas seulement dans les agences gouvernementales, mais aussi dans les banques, les assurances ou partout où l'accent est mis sur la sécurité ou sur des structures très anciennes.

Insérer une clé USB et exécuter un fichier .exe à partir de là constituerait une cause immédiate de résiliation à d’autres endroits. Je ne vous recommanderais donc pas de tenter de tout contourner.

Essayez encore une fois git

Maintenant sur votre choix. Je recommanderais fortement git au lieu de svn pour vous. De toute façon, si vous faites des projets à une personne, alors git est juste un répertoire local .gità la racine de votre application, rien d’autre.

Ne demandez pas de "SCM" gità votre supérieur / informaticien, mais demandez-leur spécifiquement de l'installer sur votre machine afin de pouvoir développer plus rapidement et avec une qualité supérieure. Faites - clair pour eux que vous ne pas souhaitez pousser votre code à un autre endroit, que vous ne pas besoin d' un serveur exécutant quelque part, et qu'il n'utiliser l' espace significatif ou le temps de maintenance.

Git augmentera la vitesse et la qualité pour vous simplement parce que vous pouvez travailler avec plus de confiance (car vous pouvez annuler toutes les modifications que vous avez apportées) et vous permettre de travailler sur plusieurs branches en même temps. Par exemple, si vous travaillez sur une tâche volumineuse et que quelque chose arrive qui nécessite votre attention immédiate, vous pouvez simplement passer à une nouvelle branche, y remédier rapidement, puis revenir à la tâche de longue durée.

Le faire manuellement

Si ce n'est tout simplement pas possible, vous pouvez bien sûr effectuer un contrôle de source manuel. Créez des "balises" manuelles en copiant votre code vous-même (créez éventuellement un nouveau répertoire avec la date / heure et une courte description de ce qui a changé). Conservez un journal des modifications avec des listes détaillées non seulement de vos modifications, mais également des fichiers que vous avez modifiés et peut-être même davantage de détails.

Créez des "branches" en copiant à nouveau votre travail et, au moment de la fusion, créez de manière créative en utilisant des outils arbitraires "diff" ou "diff3" - je ne sais pas si vous en avez disponible, vous devrez découvrir, savoir, trouver.

Si tout cela vous prend beaucoup de temps, alors examinez de près si cela vaut vraiment la peine que vous imitiez un SMC. Si vous trouvez qu'il est la peine, puis parlez avec votre patron à nouveau. Montrez-lui les avantages de votre manuel SCM (pas seulement "j'ai une copie de tout mon ancien travail" mais "quand le bogue XYZ s'est produit, j'ai immédiatement pu trouver la raison, il y a 5 versions"). Ensuite, dites-leur à quel point cela serait plus rapide git.

Évidemment, si cela vous rend fou, la recherche d’un emploi est toujours une option.

Je pense que beaucoup de gens ici manquent "l'institution gouvernementale" de cette question. Certains réseaux gouvernementaux sont soumis à des réglementations très strictes sur les logiciels, et leur violation est une infraction passible de sanctions, voire criminelles. Je le pousserais à travers la gestion pour voir si vous pouvez obtenir un mouvement APPROUVÉ lors de l'installation du logiciel. Je ne voudrais pas aller cow-boy et installer des choses moi-même. Si vous utilisez Linux / UNIX, voyez si RCS (commandes ci / co) ou SCCS (commande sccs) sont installés. Ce sont d’anciens outils de gestion de la chaîne logistique qui étaient assez standard. Ce n'est pas joli mais meilleur que ce que je vais écrire ci-dessous. :)

Puisque vous avez "beaucoup" d'espace disque, créez une arborescence source. Quelles sont les bases de la gestion de la chaîne d'approvisionnement à petite échelle? Être en mesure de vérifier les modifications, de voir ce qui a été modifié, de baliser des éléments et de revenir à d'anciennes versions, si nécessaire. Un niveau au-dessus de l’arborescence des sources, créez un Makefile ou des scripts, en fonction de vos disponibilités, en procédant comme suit (il s’agit de Linux / UNIX, les commandes Windows sont différentes)

make checkin - cp -a source-tree source-tree-date (au moins à la minute près, sinon seconde, comme source-tree-20171205115433)

make status - diff -R source-tree source-tree-date | moins (il y aurait un peu de logique ici, par défaut la sauvegarde la plus récente ou donner un argument à diff par rapport à une version

make tag - ln -s source-tree-date release1.0 (créer un lien vers une version particulière)

make revert - rm -r source-tree && cp -a source-tree-date source-tree

Le leur vendre

Vous avez laissé ce commentaire :

Ils ont un lecteur réseau dont je ne sais pas comment mais qui crée des sauvegardes par périodes. Oui. Je l'utilise et j'y stocke mes applications.

Allez vers votre supérieur et dites quelque chose dans ce sens:

Patron, j'ai remarqué que nous avions un système dans lequel nous installions des applications sur le lecteur réseau et qu'un type de service effectuait des sauvegardes et gardait une trace de l'historique. Il me semble que nous ne faisons que mettre en œuvre notre propre système de contrôle de source. Nous pourrions probablement libérer beaucoup d'espace et simplifier considérablement le système en optant pour un système de gestion de contrôle de source dédié, tel que SVN ou git. Nous aurions beaucoup d'avantages: sauvegardes simplifiées des versions historiques, outils pour comprendre les modifications apportées aux fichiers au fil du temps (informations très utiles pour le débogage), moyens plus simples pour annuler les erreurs et méthodes plus simples pour combiner les modifications apportées par différentes personnes.

J'ai déjà utilisé ce type de systèmes et ils sont très performants dans la tâche que notre configuration personnalisée effectue. Il est beaucoup plus difficile de faire des erreurs avec eux qu'avec notre système actuel. Ce sont également des technologies très matures et largement utilisées; ces outils sont largement utilisés depuis plus de 20 ans. Et en plus de cela, nous pouvons utiliser les logiciels les plus populaires sans payer un centime en licences.

Je serais heureux d'aider à choisir un client et un serveur et de les configurer. Je suppose que cela ne prendrait que des [insert estimate here]heures pour l'installer si je peux obtenir une machine. N'importe quelle machine ferait l'affaire, même un ancien poste de travail sur le point d'être retiré, tant que nous pouvons y accéder via le réseau.

Le résumé de haut niveau ici est que vous devez l'exprimer en termes qu'ils peuvent comprendre et sont susceptibles de penser que cela en vaut la peine:

• Libérer des ressources (matériel et personnes) à d'autres fins
• Risque réduit (erreur humaine, technologie stable)
• Productivité accrue
• Petit coût de mise en œuvre

Vos supérieurs ne sont pas des techniciens et ne se préoccupent pas des problèmes techniques. Mais si vous pouvez définir le problème en termes d’ argent et de choses qui coûtent de l’argent, leurs oreilles pourraient s’énerver un peu.

Après avoir lu votre question et de nombreux commentaires, j’ai bien compris que vous aviez les contraintes / scénarios suivants:

• 1 personne par projet;
• vous ne pouvez tout simplement pas utiliser d'outils externes autres que Visual Studio 2005 pour votre projet; vous ne pouvez pas utiliser GIT ou tout autre SCM;
• lorsque vous travaillez localement, vous ne pouvez pas laisser le projet en état d’échec, car vous avez des sauvegardes automatiques de temps à autre et vous devez le faire fonctionner tout le temps.
• il vous faut un peu d’historique pour suivre les changements;

Si vous ne pouvez pas utiliser Visual Source Safe (qui a un plugin pour fonctionner avec VS 2005), vous pouvez utiliser une autre approche.

Sur la base des éléments ci-dessus, je vous suggère d'organiser vos dossiers de projet tels que ci-dessous:

trunk           //last functional version of the app. IMPORTANT: YOU DON'T WORK WITH THIS FOLDER
    UnitTests   //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln
temp              //your working folder; has structure similar to trunk; changes will be commited to trunk;
    UnitTests     //important: create unitary tests in order to guarantee stuff is working after changes
    MyClassLibrary1
    MyClassLibrary2
    MyApplication
    Docs
    readme.md
    YouProject.sln  
build
    .history    //folder to contain changes in files and your comment (like commits in git)
    build.bat   //calls MSBuild to build temp\YourProject.sln, and run all unit tests
    save_on_trunk.bat   //if build is working, saves info from "diff.bat" in folder within ".history" with timestamp, and also overrides "trunk" with content from "temp"
    diff.bat         //compares files from "temp" and "trunk", using "dir" and "fc" commands
    history.bat  //outputs content from .history folder (contains file changes and comments)

Règles de base à suivre ici:

• votre contrôle de code sera effectué dans le dossier du projet;
• vous ne travaillez jamais dans le "coffre";
• vous travaillez dans "temp" , implémentez des tests unitaires , appelez build.bat , puis save_on_trunk.bat ;
• IMPORTANT: implémentez des tests unitaires qui fonctionnent en isolation totale; vous en avez besoin pour garantir que le nouveau code ne casse pas le coffre;
• puisque vous avez des sauvegardes automatiques, les chances de perdre du code seront réduites; par conséquent, il vous suffit de créer le code "tronc" pour qu'il fonctionne à tout moment.

Vous avez manqué de solutions techniques. Seules les solutions politiques restent.

1) Syndiquer les développeurs. S'il existe déjà un syndicat, contestez leur position, car ils ne représentent pas de manière juste la catégorie d'employés qui est un développeur. Si former une union de développeurs ne parvient pas à obtenir le soutien de la moitié des développeurs, allez-y. Vous êtes un mauvais ajustement.

2) Annonce dans le journal. Si votre gouvernement ne garantit pas la liberté d'expression en tant que matière reconnue par la loi, vous serez renvoyé.

Git pour Windows a une version "portable" . Vous pouvez le copier sur votre PC ou le conserver sur une clé USB sans rien installer. Si le problème est simplement l’installation, il s’agit d’une solution de contournement.

Notez que s’ils s’opposent catégoriquement à la gestion de la chaîne logistique, vous pouvez poser des questions pointues sur ISO-9001, la DO-178B ou d’autres normes de développement logiciel pertinentes.

Il suffit d’exécuter git sur un répertoire nu, sans aucun serveur impliqué. Peu importe que personne d'autre n'utilise le contrôle de version, car vous pouvez contrôler le contrôle de version de votre répertoire. Git a été conçu exactement pour ce scénario d’introduction SCM non fiable et il fonctionne bien.

Vous deviendrez un héros dès que la seconde personne commencera à l'utiliser, même si vous devez attendre qu'un dinosaure donne un coup de pied au fond pour le répandre. C'est incompétent de gérer des bases de code volumineuses sans SCM maintenant. C'est comme diriger une entreprise sans rien auditer, en fait.

En tant que développeur professionnel, vous voudriez insister sur trois choses distinctes: la révision du code, l'historique des versions et le suivi des demandes de modification.

Vous pouvez vous-même suivre les demandes de changement. Pas aussi bien qu'avec les bons outils, mais vous pouvez. La deuxième partie est des critiques de code. Pour cela, vous avez besoin de la copie précédente de votre code et d'un outil de comparaison. Lorsque vous pensez qu'un changement est prêt, vous l'examinez vous-même en comparant soigneusement la version précédente, puis vous remplacez la version précédente par une nouvelle.

Pour le contrôle de version, si votre lieu de travail n’autorise aucune solution décente, c’est une boîte de DVD inscriptibles dont vous avez besoin. Chaque fois que vous souhaitez conserver une version pour pouvoir y revenir, vous créez un nouveau DVD.

(Évidemment, tout cela n’est pas un conseil à ne pas prendre sauf si vous êtes dans un très mauvais lieu de travail, comme le PO, apparemment).