Alternatives au contrôle de version professionnel [fermé]

57

Nous faisons équipe avec des non-programmeurs (écrivains) qui ont besoin de contribuer à l'un de nos projets.

Maintenant, ils n'aiment pas l'idée d'utiliser Git (ou quoi que ce soit d'autre) pour la version contrôlant leur travail. Je pense que c'est parce qu'ils ne trouvent tout simplement pas la peine de se familiariser avec les concepts tordus du contrôle de version. (Lorsque je les ai initiés à la création de branches et à la fusion, ils avaient l'air de les offenser.)

Maintenant, nous ne sommes pas en position de les éduquer ou de les convaincre de l'utiliser. Nous essayons simplement de trouver des alternatives pour que tout leur travail soit versionné (c'est ce dont nous avons besoin) - et ils ont un flux de travail facile et se concentrent sur ce qu'ils font.

J'ai eu quelques idées ...

dites-leur de sauvegarder leur travail dans un fichier séparé chaque fois qu'ils apportent des modifications non triviales, puis utilisez un diff de notre côté pour suivre uniquement les modifications.
écrivez un programme (en Python) qui implémente les "jalons" dans CSSEdit d'une manière ou d'une autre.

À propos du projet:

C'est un système de traitement de langage naturel (écrit en C + Python). Nous avons engagé des rédacteurs pour préparer des entrées pour le système dans différentes langues. Et au fur et à mesure que nous développons le logiciel, nous aurions besoin de ces rédacteurs pour modifier leurs entrées (articles). Parfois, les modifications sont très petites (un mot ou deux) et parfois très grandes.

La raison pour laquelle nous avons besoin de contrôler la version de ces changements est que chaque changement, petit ou grand, dans l'entrée peut potentiellement modifier considérablement la sortie du système.

programming-practices version-control teamwork

— treecoder
source

15

@ rwong - ou un wiki avec versioning, cela pourrait aussi fonctionner.

— Joris Timmermans

4

En ajoutant au commentaire @MadKeithV, que diriez-vous d'un wiki propulsé par Git? github.com/github/gollum - Certains changements vont être apportés au flux de travail. Vous essayez de créer un pont entre deux équipes. Avez-vous exploré leurs outils actuels? Il y a une petite possibilité qu'ils prennent en charge une sorte de contrôle de version et vos écrivains jamais pris la peine de découvrir ..

— YANNIS

20

C'est vraiment simple. Si vous allez payer ces personnes, dites-leur qu'elles peuvent utiliser vos outils et être payées, ou si elles refusent d'utiliser vos outils, elles ne sont pas payées. N'importe quel terrain intermédiaire impliquera plus de travail de votre part, car cela coûte de l'argent et que vous devez trouver un groupe de personnes qui travailleront avec vos outils.

— Ramhound

4

Fossil est un VCS intéressant, livré avec un wiki versioned. Nous l'avons utilisé comme un moyen de garder les documents à jour, mais vous pouvez l'utiliser pour "version" des choses comme celle-ci.

— Ben Brocka

34

POURQUOI avez-vous essayé d'introduire des branches et de fusionner avec des non-techniciens? Vous voulez que leur travail soit versionné, bien. Vous pouvez leur dire comment vous voulez le sauvegarder. Vous voulez qu’ils gèrent les branches et les fusions, vous vous écartez des fonds. Vous auriez dû leur offrir quelque chose de simple et agréable, comme Tortoise *, et éviter de leur dire ce dont ils n'avaient pas besoin.

— David Thornley

102

quand je les ai introduits pour la première fois aux branches et à la fusion - on aurait dit que je les offensais

Ceci est probablement dû au fait que la création de branches et la fusion sont des concepts avancés, et infiniment moins utiles que de simplement suivre les modifications.

Alors pourquoi ne pas expliquer simplement "commettre" (enregistrer) et "mettre à jour"? Deux concepts très simples . Je suis sûr que vous pouvez l'expliquer en moins de 10 minutes.

Si vous voulez vraiment utiliser des branches distinctes et ce genre de choses, vous pouvez le faire vous-même sans les impliquer.

— Thomas Bonini
source

20

+1 Garder un historique en ligne droite est une notion radicale et qui change la donne. Je pense qu'il est peu probable qu'un écrivain ait réellement besoin de créer des branches et de fusionner, et s'il le faisait, il aurait besoin de la main d'un développeur pour pouvoir le gérer.

— Dan Ray

7

@ BillK, avez-vous réellement essayé de fusionner avec git? Je pense que cela fonctionne assez bien, bien mieux qu'avec SVN. (Je ne préconise cependant pas l'utilisation de la fusion là où ce n'est pas nécessaire.)

— svick

10

@ Bill K Honnêtement, on dirait que vous devez rattraper votre retard 20 ans plus tard sur SVN (le cas échéant). La création de branches et la fusion peuvent ne pas avoir de sens pour ces rédacteurs, mais je ne sais pas comment vous avez réussi à programmer pendant 20 ans sans jamais créer de ramification d'un référentiel. Il y a tellement de cas où les branches sont de bonnes pratiques et facilitent votre vie. en fait, rejeter le concept à l’aveuglette dénote un mauvais jugement (IMHO). En SVN, la ramification était pénible, mais avec Git, les choses sont devenues vraiment faciles. Faites-vous une faveur, surmontez votre ego et investissez un après-midi pour apprendre les bases du git. Vous ne le regretterez pas, promis!

— Robin

6

@ user606723: TortoiseSVN et TortoiseGIT offrent une intégration de shell Windows.

— Roy Tinker

6

Je suis à peu près sûr que tenter d'enseigner aux Git une branche et une fusion avec des non-techniciens constitue une violation des droits de l'homme.

— Steve Bennett

69

Une approche peu orthodoxe consisterait simplement à utiliser Dropbox . Demandez aux auteurs de sauvegarder les fichiers dans le répertoire de la boîte de dépôt et obtenez le contrôle de version et la sauvegarde gratuitement. De plus, il n’existe pratiquement aucune courbe d’apprentissage pour les auteurs.

Pour git, on dirait qu’en fin de compte, vous devrez quand même fournir aux auteurs les versions correctes des branches. Il suffit donc de placer le dépôt git dans la liste déroulante et de gérer la création de branches et la fusion pour les auteurs.

— OliverS
source

21

J'allais suggérer la même chose. Aucune raison pour laquelle vous ne pouvez pas également transformer le dossier dans Dropbox en référentiel git (ils n'ont pas besoin de savoir) et effectuer des validations périodiques (par exemple, quotidiennes). De cette façon, vous obtenez gratuitement tous les trucs sympas de Git (diffs, logs, bisects, etc.).

— Simon Whitaker

4

Assurez-vous d'utiliser la version payante, car la version gratuite n'enregistre les versions que pendant environ 30 jours si je me souviens bien.

— DMan

5

Je ne peux que -1 une réponse qui suggère un service externe, introduit un point d'échec unique et met vos données à la merci d'intrus potentiels, alors qu'il existe de nombreux logiciels utiles suggérés dans d'autres réponses et que les parties impliquées sont explicitement présentées. en tant que programmeurs capables.

— Sam Hocevar

4

@ DavidThornley: vous n'avez pas entendu parler de problèmes de sécurité réels avec Dropbox ???

— Sam Hocevar

3

Sam Hocevar: OK, maintenant je l'ai. C’était quatre heures de vulnérabilité, ce qui n’est certes pas bon, mais ne signifie pas nécessairement que c’est une mauvaise idée. Encore une fois, cela dépend de la sensibilité de l’écriture et du fait qu’une infime chance qu’elle soit vue par un étranger soit acceptable. (C'est évidemment impropre aux dossiers médicaux, mais je n'ai aucun scrupule à y laisser de mauvais projets de fiction et de logiciels inachevés.)

— David Thornley

28

En vérité, la réponse se trouve dans votre montage: "Nous avons embauché des écrivains". Parfois, vous devez simplement avoir l’esprit sanglant ... ils veulent votre argent, ils doivent faire ce que vous voulez, à condition que ce que vous voulez ne soit pas déraisonnable.

L'argument que vous avancez est l'argument que vous avez déjà avancé - nous devons être capables de faire X, Y et Z pour que le produit fonctionne, et pour ce faire, nous avons besoin de vous pour le faire. Nous serons aussi solidaires que possible, mais pour que cela fonctionne (et donc que cela continue comme source de revenus pour vous, l'auteur), cela doit arriver.

Je suis plutôt d’accord pour dire qu’une solution appropriée basée sur un wiki semblerait être un bon compromis - mais le défi consiste à trouver un compromis entre leur flux de travail et vos exigences.

Je vais répéter le point clé - pour que votre projet soit un succès que vous avez besoin des articles à versionné donc ceux qui travaillent sur les articles doivent jouer par un ensemble de règles convenues, si cela ne vous arrive pas vous obtenir brûlés et, par extension, les écrivains le seront aussi.

— Murph
source

Je suis totalement d'accord avec vous. Mais vous voyez qu'il y a quelque chose appelé "gestion" entre nous (l'équipe de programmeurs) et les écrivains. La direction a embauché les rédacteurs et nous a demandé de travailler avec eux. Le fait qu’ils soient réticents à l’apprentissage du contrôle de version est quelque chose que la direction considère comme un problème qui doit être «ajusté» entre nous (l’équipe) et eux (les programmeurs).

— Treecoder

1

J'ai en quelque sorte deviné ... mais alors vous devez présenter votre cas à la direction, et c'est le même cas. Ils ont raison de dire que c'est quelque chose qui doit être "ajusté" (choix de mot intéressant) - mais le compromis est une chose à double sens, vous devez leur donner quelque chose avec lequel ils peuvent travailler, ils doivent travailler avec cela.

— Murph

Yay - vote négatif sans explication, toujours comme ceux-là.

— Murph

2

@greengit Les problèmes qui doivent être "ajustés" entre les équipes font partie de l'objectif de la gestion. Déléguer la responsabilité à une équipe est soit paresseux, soit peut-être une indication que la direction préférerait l'approche de cette équipe. Je suggérerais donc que vous suggériez à la direction la solution qui vous semble la plus logique et laissez-les s’inquiéter de tout le reste.

— Yannis

3

J'ai tendance à présenter ces "ajustements" à la direction sous forme de budget pour les modifications proposées. "Bien sûr, nous pouvons éviter de les utiliser (git,…). Nous devrons engager une secrétaire pour le faire à leur place. Inscrivez-vous ici et je commencerai les entretiens lundi."

— BRPocock

18

J'ai déjà dû faire face à une situation similaire comme celle-ci. En fin de compte, nous avons simplement désigné un développeur (moi) comme point de contact du contrôle de version pour le tiers.

La tierce partie m'envoyait chaque jour un fichier zip contenant leurs fichiers de projet et je les archivais. J'ai configuré un espace de travail de projet distinct et un compte svn pour eux et je décompressais les fichiers dans cet espace de travail en écrasant ce qui se trouvait là, puis en effectuant l'archivage sous ce compte.

Ce n’était pas très amusant de faire tous les jours, mais il est parfois plus important de simplement faire le travail.

L'un des avantages était que cela m'aidait à revoir leur travail pour m'assurer qu'ils ne vérifiaient pas le code défectueux et les données qui briseraient la construction.

— Alan Barber
source

+1 Si cela était possible, le problème serait résolu! pour nous. Ce n'est pas parce que nous sommes une petite entreprise et je ne pense pas que suggérer d'épargner un développeur en partie ou uniquement à cette tâche me rendrait tout sourire, de la part de la direction (idiote). Vraiment, je pense à notre gestion de cette façon.

— Treecoder

2

@greengit - Si vous suggérez que c'est la seule solution qui fonctionnerait, les coûts forceront la direction à engager différentes personnes, qui travailleront avec vos outils. Bien sûr, vous pouvez expliquer à la direction que TOUTE solution, sauf le contrôle de version, vous coûtera de l’argent, que vous travailliez sur des problèmes (et les résolvions) créés par le contournement ou que vous passiez un peu plus de temps à essayer d’empêcher les problèmes (sauf si vous ignorez ces deux points clés). , les problèmes vont arriver, en fait ils vont arriver quoi qu'il arrive).

— Ramhound

3

@greengit Évidemment, cela dépendra de tout ce qui est impliqué dans votre processus, mais dans mon cas, cela m'a pris moins de 5 minutes par jour pour archiver les fichiers tiers. C'était ma solution pour éviter les pertes de temps en essayant de développer un processus et de former la 3ème partie à ce sujet.

— Alan Barber

Cela ne devrait pas être si difficile. Une personne est l'interface entre les rédacteurs et le système de contrôle de version. Ils savent lui soumettre tous leurs changements. Il ne devrait pas lui prendre plus d’une minute ou deux pour abandonner leurs modifications et les engager.

— Dan Ray

@greengit - Cela allait être ma réponse. Oui, cela prendrait du temps avant de faire un travail utile. Écrire un système personnalisé (ce que vous semblez vouloir faire) prendrait plus de temps. Et les écrivains se plaindraient encore.

— Mike Baranczak

18

SparkleShare est un clone dropbox basé sur git, je pense que cela répond à vos besoins.

SparkleShare crée un dossier spécial sur votre ordinateur. Vous pouvez ajouter des dossiers hébergés à distance (ou "projets") à ce dossier. Ces projets seront automatiquement synchronisés avec l'hôte et tous vos pairs lorsqu'un utilisateur ajoute, supprime ou édite un fichier.

... voici quelques exemples de ce qu'il fait bien et moins bien avec les visages souriants:

Génial

Modification fréquente des fichiers de projet, tels que du texte, des documents bureautiques et des images

Suivi et synchronisation des fichiers édités par plusieurs personnes

Rétablir un fichier à n'importe quel moment de son histoire

Prévention de l'espionnage de vos fichiers sur le serveur à l'aide du cryptage

Pas si bien

Sauvegardes informatiques complètes

Stocker votre photo ou votre collection de musique

Les gros fichiers binaires qui changent souvent, comme les projets de montage vidéo ...

Mise à jour (novembre 2015) : le projet semble être abandonné (dernière version d'avril 2014).

— moucheron
source

Très prometteur, mais peut-être un peu immature. Je vais certainement garder un oeil sur cela cependant.

— Zsolt Török

13

Si vous pouvez fournir un espace de travail préparé avec une utilisation transparente de VCS, ils utiliseront VCS. Ne pas apprendre aux non-programmeurs à utiliser VCS à la manière d'un programmeur

Il suffit de rechercher un éditeur avec prise en charge intégrée de VCS, de le configurer et d’afficher des étapes simples supplémentaires dans ses travaux.

Un exemple - Editplus connaît Subversion et peut effectuer des opérations SVN de base dans la fenêtre de l'éditeur. Le dernier Editplus peut même utiliser TortoiseGIT pour l'intégration Git

Edit : solution de remplacement: EasySVN , qui, correctement configuré, surveille la copie de travail et effectue la validation automatique, ce qui permet d' utiliser n'importe quel outil de création pour l'utilisateur final et les formats de documents

— Lazy Badger
source

11

Qu'en est-il de la création d'un WebDAV ?

Il gérera automatiquement l'historique des versions en ligne droite pour eux. Tout ce qu'ils ont à faire est de se connecter au serveur comme s'il s'agissait d'un lecteur réseau et chaque sauvegarde constituerait un commit.

— Malfiste
source

+1 pour WebDAV. Je n'ai vraiment pas pensé à cette option. Combien de temps pensez-vous qu'il sera difficile de déployer et de maintenir un serveur WebDAV (+ workflow)

— treecoder

C'est très simple, vous installez apache, subversion, un repo. Ensuite, vous installez le module apache, vous le configurez et vous avez terminé.

— Malfist

-1 car "automagiquement" n'est pas un mot.

— dreftymac

4

@dreftymac fr.wikipedia.org/wiki/Hair-splitting

— SplinterReality

1

Peut-être pourriez-vous rendre cette réponse plus explicite: Configurez Subversion + Apache + WebDAV sur un serveur et montez le partage WebDAV à partir des clients non-développeurs. Demandez aux utilisateurs de sauvegarder leur travail sur le partage WebDAV au moins une fois par jour.

— Jan

7

Google Docs

Google Docs peut faire ce que vous voulez. File > See Revision Historyvous permettra de suivre les changements.

Vous avez également le problème de la manipulation des fichiers, pris en charge gratuitement; Il suffit de partager le document avec tout le monde.

Enfin, il est facile à utiliser. les rédacteurs n'ont même pas besoin de savoir qu'il existe des versions.

— Nathan Long
source

6

OS agnostique

Ecrivez un programme Python sur lequel vous pouvez glisser et déposer un fichier, ce programme peut alors faire le git addet git commitet ce qui ne l'est pas et ils n'ont jamais à s'en occuper.

ou

Utilisez un système de fichiers basé sur WebDav que vous pouvez monter sur leur ordinateur et que le serveur gitgère de manière transparente.

OSX / Linux

Ecrivez un plugin FUSE basé sur Python qui prend les fichiers et les engage dans git. Ensuite, ils peuvent simplement ouvrir et enregistrer de manière transparente à partir du système de fichiers monté. Il existe des ressources FUSE pour Windows , mais elles ne valent probablement pas la peine d’être trompées.

les fenêtres

Vous pourriez peut-être écrire du code pour utiliser les pilotes de filtres FileSystem afin de procéder de manière transparente git.

— utilisateur7519
source

5

Ah, les joies des non-codeurs déconnent. Je suggère de mettre en place un environnement git / mercurial pour eux. Dites-leur de tout enregistrer dans un format compatible avec le référentiel. Avec tortoisegit ou tortoisehg , ils n’ont pas besoin de savoir comment fonctionne le repo. Ils vérifient simplement s'ils ont un point d'exclamation dans leur répertoire de projet, font un clic droit sur le fichier incriminé et cliquez sur commit. Tapez un résumé des modifications (ce sont des écrivains, n'est-ce pas?) Et vous avez terminé!

Une étape supplémentaire dans le flux de travail pour eux, mais rien sur la fusion / branchement / cool. L'environnement prédéfini est déjà configuré pour figurer dans la branche writer, de sorte qu'ils ne voient pas le code. Demandez à un script de les synchroniser automatiquement tous les jours. Plus tard, une fois qu'ils sont habitués à commettre, vous pouvez leur montrer des fonctionnalités supplémentaires. La possibilité de voir ce qui a changé quand est si utile qu'ils ne pourront plus s'en passer, une fois que vous l'aurez inséré dans leur flux de travail.

— Spencer Rathbun
source

5

Une chose que je me suis rendu compte, c’est que tous les rédacteurs non techniques (YMMV) considèrent simplement leur travail précédent comme inutile, une fois qu’ils y ont apporté des modifications. Ils pensent que le travail mis à jour (article ou quoi que ce soit qu'ils écrivent) soit le meilleur, et il est stupide de garder les versions antérieures de celui-ci. Bien que dans notre cas, nous leur avons au moins expliqué avec succès pourquoi nous avons également besoin de l'historique.

— Treecoder

@greengit peut-être. Si vous montrez comment vous les adaptez à la direction, en quoi cette étape simple et facile vous aide et comment cela permet à l'entreprise de réaliser des économies / de gagner de l'argent, elle devra le faire quand même. Les activités dépendent des résultats financiers. Informez donc le patron que cela intègre les rédacteurs dans le pipeline technique et permet de faire des économies sur les coûts d'intégration, les sauvegardes (vous sauvegardez le repo, n'est-ce pas?) Et la transmission d'informations.

— Spencer Rathbun

+1 Nous avons également configuré nos coordinateurs de projet et nos agents du service clientèle pour qu'ils utilisent TortoiseSVN. Après l'explication initiale (et en les aidant avec la caisse initiale), ils n'ont pas eu de difficulté à valider leurs versions modifiées (principalement des documents bureautiques et des images de maquettes). Ils ont même aimé qu'ils obtiendraient automatiquement la dernière version si un collègue changeait quelque chose.

— Sleske

3

Qu'en est-il de Share Point? Je sais que ce n'est pas populaire dans les mondes du développement, mais si vos auteurs utilisent Windows comme système d'exploitation, cela fonctionnera bien et ils ne sauront pas vraiment qu'ils utilisent le contrôle de version (un gros plus pour mon travail).

Cette solution les empêche également de faire face à tout ce qui pourrait leur faire peur, car il semble qu’ils soient frileux de choses nouvelles.

— JustinDoesWork
source

+1 car c'est ce que notre équipe est déjà en train de faire et ça marche.

— sq33G

Je préfère travailler avec un système de contrôle de version approprié pour SharePoint, qui contient une partie de la documentation de notre société, car le téléchargement de nouvelles versions sur SharePoint nécessite plus de travail.

— Chris Morgan

2

Pourriez-vous configurer un outil qui surveille le système de fichiers dans lequel les rédacteurs enregistrent leurs fichiers et le faire procéder à une validation automatique à chaque fois qu'il enregistre?

Si vous le mettez sur un partage réseau, vous pouvez effectuer toute la configuration sans les impliquer du tout. mais chaque fois qu'ils fourniraient une version mise à jour à votre équipe, celle-ci serait ajoutée à git pour vous.

— Dan Neely
source

1

Avez-vous regardé Plastic SCM. Ils essaient de le rendre plus simple à utiliser

Si vous souhaitez uniquement des sauvegardes versionnées, vous pouvez utiliser Dropbox ou configurer le service de sauvegarde Windows. Ou vous pouvez installer Crashplan ou un autre produit similaire.

— Amala
source

+1 pour m'avoir orienté vers une nouvelle offre commerciale dans le domaine DVCS

— Roland Tepp

1

Pour Mercurial DVCS, il existe une interface utilisateur appelée EasyMercurial , dont l'objectif déclaré est explicitement de fournir une vue simple des opérations de contrôle de version de base.

EasyMercurial est destiné à être:

simple à enseigner et à apprendre indicative de l'état réel du référentiel, en utilisant une représentation graphique d'historique

manifestement proche d'un flux de travail en ligne de commande normal pour Mercurial cohérent sur toutes les plates-formes

Nous n'essayons pas de produire "le meilleur" client Mercurial dans un seul but. Nous encourageons activement les utilisateurs à s’adresser à d’autres clients à mesure que leurs besoins évoluent. L'objectif est simplement de fournir quelque chose accessible aux débutants dans de petits groupes de projets travaillant avec un référentiel distant partagé.

Je recommanderais d'essayer.

— Laurens Holst
source

1

J'ai souvent dû travailler avec des non-programmeurs (principalement des graphistes, et si vos rédacteurs ont aussi peu d'indications sur la gestion des fichiers de travail en tant qu'artistes, alors vous êtes pris pour ... h'mmm ... amusement .. .) Il y a trois approches possibles:

Imaginez qu'ils sont des programmeurs, essayez de leur apprendre à utiliser le contrôle de version. Cela ne fonctionnera pas et vous aurez des combats constants.
Ecrivez-leur un outil très simple qui saisit la version actuelle et la colle quelque part afin de pouvoir revenir en arrière dans les fichiers d’hier si nécessaire. C’est possible, et j’ai fait cela pour une équipe de créateurs de DVD (création de menus, de graphiques, etc.) il ya plusieurs années avec un certain succès: l’outil que j’ai écrit était un wrapper en un clic pour PkZip (vous pouvez voir que c’était il y a quelque temps) et il vient de compresser le répertoire de travail et de nommer l'archive pour la date + heure.
Prenez le contrôle de ce qu'ils produisent vous-même. Indiquez clairement que leurs fichiers doivent être remis à un programmeur et ne font partie du projet que lorsque le programmeur les accepte: le programmeur les contrôle ensuite dans le contrôle de version et le contenu est géré de manière professionnelle.

Personnellement, je pense que l'option 3 est la voie à suivre. Cela signifie douleur et irritation pour quiconque doit prendre les envois de fichiers et les faire enregistrer, mais beaucoup moins que toute autre option.

Je dirais aussi que les non-programmeurs livrent des fichiers avec n'importe quel ancien nom de fichier auquel vous pouvez penser. Les conventions de nommage leur sont étrangement étrangères. Ils vous donneront un fichier appelé "Image" ou quelque chose, puis quand vous leur direz ce qui ne va pas, vous obtiendrez un fichier appelé "Picture_Final", qui ne corrigera qu'environ 3 des fautes. Lorsque vous le signalez, vous obtenez un autre fichier, appelé "Picture_NewFinal", puis "Picture_NewFinal2" (si vous avez de la chance), bien qu'il soit possible à ce stade qu'ils abandonnent toute idée de développement historique et qu'ils l'appellent "Icône de clé chose".

Encore une fois, vous pouvez essayer d'appliquer une convention de dénomination, ce qui signifie leur dire à l'avance comment chaque fichier doit être appelé, ou vous pouvez passer des heures à déchiffrer et renommer ce qu'ils vous envoient. Ici, je dirais que vous voulez de toute façon un tableur pour votre santé mentale, essayez donc de le leur faire suivre: ne soyez pas surpris quand ils ne le font pas.

J'espère que ça aide - amusez-vous!

— AAT
source

0

S'il y a une chance que deux d'entre eux doivent travailler sur la même cible à la fois ET si vous pouvez gérer tout leur travail dans des fichiers texte, je vais essayer de partager Google Docs.

Il a une capacité de collaboration / éditeur multiple impressionnante - de loin le meilleur que j'ai jamais vu. Ils sont également intégralement versionnés et peuvent être exportés sous forme de fichiers texte.

Mais ce sont deux très gros si.

— Bill K
source

0

Laissez-les travailler dans un dossier en sauvegardant les fichiers comme d'habitude.

Une fois par jour (ou par semaine, etc.), copiez le contenu de ce dossier dans backup_dd_mm_yyyy. Le code source de la plupart des systèmes occupe une quantité d'espace minime compte tenu de l'espace disponible de nos jours.

La copie peut être faite par vous, eux-mêmes, un tiers, un outil ou un script.

Cela limite les pertes à un jour, donne une histoire, est transparent pour eux.

Pas parfait pour les deux parties mais une réponse qui cherche à trouver un terrain d'entente.

— Michael Durrant
source