Outils de collaboration pour les nuls / professeurs

Supposons que des coauteurs de deux institutions différentes ou plus écrivent un article en latex et souhaitent faire mieux que d’envoyer des brouillons de manière répétée.

Ils réalisent qu'ils peuvent ouvrir gratuitement un compte Dropbox, partager le mot de passe et synchroniser la version du papier sur leur ordinateur avec celle de Dropbox. Si deux personnes modifient simultanément la même section, elles écraseront les modifications.

Ils ont également entendu dire que les systèmes de contrôle de versions tels que SVN et Git disposent d'outils permettant de fusionner des modifications simultanées, qui fonctionnent relativement bien. Cependant, la documentation de ces produits est plutôt difficile à lire, et elle est plus centrée sur la manière d’annuler les changements et de gérer différentes "branches" plutôt que sur les besoins fondamentaux des coauteurs qui écrivent un article.

Existe-t-il une explication pas à pas simple sur l’utilisation d’un système de contrôle de version dans cette configuration:

• référentiel central
• copies locales
• fusion "intelligente"
• pas de branches

?

Parmi les systèmes de contrôle de version standard, lequel est le plus facile à utiliser? (Nous parlons ici de professeurs théoriques en informatique.)

Existe-t-il des outils encore plus simples qui ne synchronisent qu'avec la fusion intelligente, sans contrôle de version?

Inversement, les personnes qui utilisent des systèmes de contrôle de version pour écrire même un article avec un seul auteur sentent-elles vraiment que la fonctionnalité illimité-annulation vaut la complexité supplémentaire?

Tout d'abord: si vous êtes intéressé par l'édition collaborative en temps réel, essayez quelque chose comme Gobby . Il vous permet de modifier littéralement un document en même temps.

En ce qui concerne les systèmes de révision, je ne connais que SVN. C’est ce que vous faites, après avoir installé Subversion, bien sûr:

1. Demandez à quelqu'un de vous configurer un référentiel et de vous donner l'URL, le nom d'utilisateur et le mot de passe
2. Allez à l'endroit où vous voulez avoir votre copie locale
3. Dans un shell (ligne de commande?), Tapez: svn co url://to.your/repository(check-out). Un nouveau dossier contenant le contenu du référentiel apparaît maintenant.

C'est tout. Maintenant les commandes les plus basiques:

• Chaque fois que vous ajoutez un nouveau fichier foo, entrez:svn add foo
• Chaque fois que vous souhaitez supprimer un fichier, entrez: svn rm foo
• Chaque fois que vous avez apporté des modifications, entrez: svn ci(enregistrement)
• Chaque fois que vous souhaitez obtenir les derniers éléments, entrez: svn up(update)

Il y a aussi des commandes pour déplacer, copier, créer des branches, résoudre des conflits, ... mais tant que vous n'essayez pas de trucs marrants, vous êtes d'accord avec ce qui précède. Si quelque chose se brise ou semble le faire, sauvegardez vos modifications, supprimez tout le dossier et récupérez-le à nouveau. C'est pour svn comme redémarrer pour Windows.

Addendum: Je vois que vous semblez vous préoccuper des "fusions intelligentes". Je suppose que vous faites référence à différentes versions d’un fichier fusionné, en supposant que deux personnes ont ajouté des éléments dans des parties disjointes du document. Autant que je sache, svn considérerait cela comme un conflit, et probablement à juste titre. Je ne pense pas qu'il existe une procédure générale garantissant que vous obtenez ce que vous voulez après que deux personnes aient manipulé la même source. Il existe des clients svn graphiques qui permettent de visualiser ces conflits et de vous aider à les résoudre. ce sont plutôt des visionneuses de diff où vous pouvez choisir quelle version garder pour chaque ligne en conflit). Cela nécessitera du travail, cependant.

Je remarque que personne ne donne le "petit" tutoriel pour GIT , je vais donc essayer de le couvrir. GIT est plus rapide et supérieur à SVN, mais il est peut-être plus facile d’obtenir un compte SVN sur un serveur de votre université, car SVN est bien établi. De plus, vos collaborateurs sauront comment l'utiliser.

Même si vous collaborez avec SVN, vous voudrez peut-être utiliser GIT pour votre propre versioning local (je le fais!).

Premier avertissement : GIT est très puissant et pour une utilisation basique, il est légèrement plus difficile à utiliser que SVN (par exemple, une option à ajouter dans la ligne de commande; deux étapes pour le référentiel central).

$\Delta$ comme ils l'appellent) même si l'ensemble couvre plusieurs fichiers. Dans GIT, vous avez également la notion de référentiel local et de référentiel central . BON : Vous pouvez travailler hors ligne. BAD : Deux étapes doivent être validées sur un serveur central .

Commandes de base en supposant que vous avez déjà un référentiel

• Cloner un référentiel: git clone <url>
• Mettez à jour votre référentiel local: git pull <repo>ou simplement git pullsi vous avez cloné comme ci-dessus.
• La commande pull fait vraiment les deux git fetchet git merge. L'ancien "fetch" du serveur central, et le second applique une fusion de vos fichiers et de ceux du serveur.

La fusion est automatique tant qu'il n'y a pas de modifications simultanées sur les mêmes parties de certains fichiers. Si la fusion échoue, votre répertoire de travail reste dans un "état de fusion", ce qui signifie que vous devez résoudre les conflits, puis que vous devez valider la copie fusionnée. Si vous avez toujours des conflits non gérés dans vos fichiers, la validation échouera à nouveau, aucune erreur ne sera commise.

• Ajouter un nouveau fichier à commettre: git add <file name>.
• Valider les modifications dans votre référentiel local : git commit -am "<textmessages>"ou git commit -asi vous souhaitez modifier les messages de validation.
• Poussez les changements dans votre local référentiel vers le référentiel central .

Notez que pour appliquer des modifications à votre référentiel central, vous devez d’abord vous engager dans votre système. référentiel local et vous devez appliquer tous les commits (même plus d’un) à votre référentiel central .

Créer un référentiel local d'utilisateurs

• Création d'un référentiel git initdans le dossier de votre choix.
• Terminé!

Créez un dépôt partagé avec le public (également privé si vous payez en espèces) avec une belle interface graphique.

• Utilisez GitHub

Créez autant de référentiels privés / publics avec différents groupes d’utilisateurs, mais sans interface graphique.

• Demandez un compte SSH sans mot de passe sur une machine accessible.
• Ne vous inquiétez pas, car l'authentification est effectuée à l'aide de clés SSH.
• Installez Gitosis selon ce tutoriel .
• Vous pouvez maintenant administrer votre propre serveur git en éditant un seul fichier et en l'enregistrant dans le référentiel!

Git n'a pas besoin d'un serveur central : n'importe quel dossier de votre ordinateur peut être utilisé comme référentiel afin que vous puissiez jouer avec git et faire vos tests hors ligne. Vous pouvez initialiser un référentiel et simuler trois collaborateurs dans trois autres dossiers sans envoyer un bit sur le réseau. En effet, toute copie clonée du référentiel est un référentiel complet que vous pouvez valider. C'est bien si vous voulez travailler sur un vol entre les États-Unis, la Chine ou l'Europe.

Google Documents ( https://docs.google.com ) fournit d'excellents outils pour la création de documents ensemble (y compris l'édition en temps réel). Il stocke tout en ligne pour vous et s'intègre bien à votre compte Gmail. Par défaut, Google Docs n’a pas de compatibilité LaTeX, mais vous pouvez l’activer en allant ici:

http://docs.latexlab.org/

Je ne sais pas si cela fonctionne bien pour le retour en arrière, mais je suis sûr qu'il existe une fonctionnalité pour cela. J'ai entendu parler de personnes utilisant le plug-in LaTeX de Google Wave pour élaborer des esquisses préliminaires de documents.

Je fais apprendre à Mercurial à mes co-auteurs et je leur faisais apprendre Subversion. Si vous êtes un fan de Subversion, lisez simplement ceci : tout est vrai.

Quel que soit le système que vous utilisez, le plus difficile est de loin de demander à une autre personne d'installer le logiciel et de commencer à l'utiliser. Skype est la solution parfaite. Les versions récentes de Skype autorisent le "partage de bureau", ce qui est vraiment utile lorsque vous souhaitez guider votre co-auteur tout au long de la procédure d'installation. Et j’ai utilisé le partage de bureau droit en combinaison avec Skype pour écrire un document avec mon co-auteur. Ça marche plutôt bien.

Ce qu'il faut vraiment, c'est un "Github pour les scientifiques". Quelque chose qui donne un référentiel, a le contrôle de version, l'édition collaborative, etc. Devinez quoi, il y a http://www.scribtex.com/ .

voici un nouvel éditeur collaboratif en ligne de latex appelé WriteLatex qui semble prometteur et constitue un quasi-guichet unique pour de nombreux besoins / exigences en matière d’écriture scientifique.

• fonctionne sur mobile
• a aperçu en temps réel
• partage facile / privé
• trouve des erreurs de latex
• permet d'ajouter des bibliothèques / styles de latex
• stockage en ligne

le co-auteur John Hammersley a posté une annonce dans tcs se meta ici et il réagit aux commentaires (5 votes supplémentaires sur l'annonce et elle apparaîtra sur le site principal). il semble que cela pourrait devenir un outil précieux pour la communauté tcs au fil du temps et peut-être que les auteurs seront en mesure de mettre en œuvre certaines fonctionnalités populaires spécifiquement sur demande.

Qu'en est-il des systèmes simples, des solutions:

• Google Docs, rédacteur Zoho ... et d'autres outils collaboratifs.
• Dropbox gère les situations où deux personnes tentent de valider des modifications sur le même fichier. La deuxième personne qui commet son fichier est renommé (X.txt -> X.txt_blabla ...) et le fichier original (X.txt) mis à jour avec la version la plus récente. Plus d'infos sur: Dropbox Help: "Que se passe-t-il si deux personnes changent le même fichier?"

Cela est hors de question, mais il y a parfois des situations dans lesquelles une partie du groupe est capable de solutions simples comme SVN, tandis qu'une autre partie du groupe est capable du contrôle de version distribuée comme GIT. Dans de telles situations, la coopération est possible:

• git-svn - Opération bidirectionnelle entre un dépôt Subversion et git
• Git - Cours intensif SVN
• Utiliser efficacement Git avec Subversion

J'ai récemment découvert sharelatex.com et je l' ai utilisé avec mon collaborateur pour co-écrire un article. Cela m'a tellement plu que mon plan actuel est de l'utiliser pour tous mes projets. Quelques caractéristiques notables:

• TeXing dans le navigateur en temps réel (comme Google Docs, mais conçu pour TeX, la coloration syntaxique, etc.).

• Compilation dans le navigateur et affichage au format PDF

• Prend en charge les projets avec plusieurs fichiers

• A une fonction d'histoire

• Synchronise avec Dropbox (bientôt disponible en version bêta). De cette façon, vous pouvez transférer la sauvegarde des sauvegardes, etc. sur Dropbox. En fonction de la procédure, cela devrait également vous permettre d'utiliser sharelatex même si vos co-auteurs ne le souhaitent pas, à condition qu'ils soient disposés à utiliser Dropbox pour partager des fichiers.

• Vous pouvez télécharger / télécharger votre projet à tout moment, pour que vous ne soyez pas bloqué par sharelatex en cas de problème, si vous changez d'avis ou autre.

Le seul inconvénient (mais je pense que cela en vaut la peine): bien que l’utilisation de sharelatex soit gratuite, certaines de ses fonctionnalités ne le sont pas. Notamment, pour utiliser Dropbox sync (quand ils le publient), ou si vous voulez que plus de 6 coauteurs travaillent sur le même projet sharelatex, vous devez payer 8 $ / mois. ou $ 80 par an [à compter d'avril 2013]. Une fois la synchronisation Dropbox publiée, cela me semble être un prix très raisonnable.

[Avertissement: je n’ai aucune relation avec sharelatex ou ses employés si ce n’est que j’utilise leur produit.]

SVN est l'outil développé à cet effet. Je mettrais l'effort pour l'apprendre. Il n’est pas plus compliqué que d’apprendre à utiliser le logiciel algorithme Latex ou l’un des logiciels Latex créateur de diapositives pdf.

Ceci dit, j'utilise CVS au lieu de SVN. Il existe un meilleur support des administrateurs CS de notre institution (le serveur SVN est davantage géré par les utilisateurs). De plus, j'apprécie le fait que les fichiers de version sous-jacents sont toujours là et modifiables si quelque chose ne va pas très bien.

Il y a 2 inconvénients par rapport au SVN. Les renommage de fichiers ne sont pas aussi agréables, mais je peux vivre avec cela (choisir un bon nom pour la première fois). Le deuxième problème est qu’il faut un compte CS local pour accéder au référentiel. Par conséquent, l'accès depuis une autre institution n'est possible que si un compte est créé en premier. Bien sûr, je ne m'attends pas à ce que ce soit un problème réel où que ce soit; un membre du département local peut probablement parrainer ce compte.

La restriction d'accès local est due au fait que les administrateurs ne veulent pas prendre en charge un pserver. (Plus difficile à sécuriser, etc.)