Contrôle de version pour la collaboration (avec des différences au niveau des mots)?

La plupart des articles sont maintenant rédigés en collaboration, et les collaborateurs sont souvent situés dans des endroits différents. J'ai toujours utilisé des systèmes de contrôle de version pour mes documents et mon code, et j'ai également trouvé le contrôle de version critique pour les projets logiciels collaboratifs, mais il semble que de nombreux chercheurs en théorie évitent leur utilisation pour écrire des articles communs. Pour convaincre mes collaborateurs que le contrôle de version (contrôle de révision) est une bonne idée pour travailler ensemble, il semble y avoir des conditions préalables. Il n'est pas possible de forcer tout le monde à s'inquiéter d'un ensemble spécifique de conventions pour les sauts de ligne et les paragraphes, ou pour éviter les conversions tab / espace.

Quelqu'un propose-t-il l'hébergement gratuit de petits référentiels de documents partagés, avec un contrôle de version convivial pour les documents texte qui peut gérer les différences au niveau des mots ( pas en ligne)?

Sinon, j'accueillerais volontiers d'autres suggestions basées sur l'expérience (évitons les spéculations, s'il vous plaît).

Je pensais à Git, Subversion, Mercurial, darcs ou Bazaar, mis en place pour gérer les différences au niveau des mots avec wdiff, ainsi qu'à un moyen simple de configurer l'accès sécurisé par des clés publiques (par exemple via ssh). Cependant, aucun des fournisseurs de contrôle de version que j'ai examinés ne semble offrir quelque chose comme ça. Pour la collaboration scientifique, les caractéristiques «entreprise» soulignées par nombre de ces entreprises ne sont pas très importantes (nombreuses succursales, intégration avec trac, audit par des tiers, équipes de projet hiérarchiques). Mais les différences au niveau des mots semblent critiques mais non prises en charge. D'après mon expérience, avec les différences de niveau ligne pour les fichiers texte, tout le monde doit éviter de reformater les paragraphes et les éditeurs qui changent les tabulations en espaces ou vice versa causent des problèmes; il semble également y avoir de nombreux conflits de modification parasites.

Voir la question connexe à MO sur les outils de collaboration et les questions connexes sur TeX.SE, à propos du contrôle de version pour les documents LaTeX et des packages LaTeX pour le contrôle de version . Voir également le tableau d'examen de comparaison d'hébergement SVN pour une grande liste de fournisseurs d'hébergement, pour un seul des principaux systèmes de contrôle de version.

Edit: La réponse de Jukka Suomela à la question TeX.SE "Les meilleurs outils de diff et de fusion compatibles avec LaTeX pour la subversion " semble être la meilleure suggestion jusqu'à présent, couvrant la façon d'interpréter les deltas au niveau des mots. De plus, Jukka a expliqué comment les différences entre les versions successives du côté du référentiel sont distinctes des différences au niveau de l'utilisateur utilisées pour la détection des conflits et la fusion des modifications. La réponse de Jukka à TeX.SE exclut explicitement les modifications et les fusions simultanées, en s'appuyant plutôt sur le jeton de modification atomique traditionnel pour éviter les conflits de modification. En clarifiant (et en modifiant) ma question initiale, existe-t-il un moyen de garantir que les conflits d'édition peuvent être résolus sur la base d'une différence de mots plutôt que sur une base de différence de ligne? En d'autres termes, peutwdiffou des outils similaires soient-ils intégrés dans la partie détection des conflits des outils de contrôle de version, de la même manière que les différences de fin de ligne et les espaces blancs peuvent être ignorés?

J'ai utilisé git pour collaborer sur certains documents écrits en latex. Vous devrez respecter certaines règles:

• Commencez chaque phrase sur une nouvelle ligne, latex ignore ces nouvelles lignes tant qu'il n'y a pas de ligne vierge
• Utilisez la même configuration pour le formatage (tabulation / espaces / largeur maximale du texte)
• Pour de meilleurs résultats, créez un fichier .gitattributes dans votre référentiel et ajoutez la ligne *.tex diff=tex. Cela rend diff conscient de la syntaxe tex et conduit à une sortie plus significative.

Vous pouvez ensuite utiliser git diff --color-wordset gitk --color-wordspour voir les différences de mots (voir également cet article Différences mot à mot dans Git sur la façon de configurer git pour toujours utiliser l'algorithme word-diff pour afficher le journal git diff / git).

Pour réduire les fusions manuelles, je peux recommander d'utiliser des fichiers séparés pour les sections et sous-sections (selon la taille de votre document).

Je suggère de jeter un œil à:

LaTeX / Rédaction collaborative de documents LaTeX ,

et le document connexe:

Outils pour la rédaction collaborative de documents scientifiques LaTeX .

Je veux vraiment faire écho aux autres et vous suggérer de vous asseoir et d'élaborer une belle stratégie SVN. J'utilise SVN pour héberger l'ensemble de ma structure "recherche":

• Gestion des références JabRef
• PDF téléchargés
• Des articles

C'est génial car il contient tout et fournit bien sûr une histoire. La mise en garde étant que vous avez besoin de votre propre serveur. Mais si vous avez une machine Windows existante (ou quoi que vous soyez à l'aise), vous pouvez l'installer simplement via VisualSVN Server . Vous créez ensuite des comptes appropriés pour les collaborateurs et leur donnez accès à une zone appropriée (c'est-à-dire peut-être un accès en lecture à votre fichier bibtex JabRef et une lecture / écriture dans une zone d'article partagée en cours).

TortiseSVN peut être utilisé comme client Windows pour interagir avec SVN. Vous devez être prudent lorsque vous déplacez / supprimez des fichiers et copiez des dossiers (SVN stockera les métadonnées dans des dossiers cachés dans chacun de vos dossiers, vous devez donc exécuter la commande de suppression à partir de SVN pour vous en débarrasser, cela prend un peu de temps pour être utilisé). à, mais vaut l'investissement).

Ensuite, lorsqu'ils travaillent avec un collaborateur, ils doivent clairement utiliser également SVN. Mais, encore une fois, l'investissement dans l'apprentissage n'est pas sans valeur. Et via une réflexion, vous pouvez également l'avoir afin que vous ayez un accès en lecture seule à leur fichier jabref (peut-être via la fonction 'externe' de svn).

De cette façon, avec un peu de réflexion et un peu d'effort, vous pouvez être dans une situation où vous modifiez des documents comme d'habitude, commettez des changements tous les soirs, mettez à jour le matin et résolvez facilement tous les conflits.

Je le recommande vraiment. Plus il y a de personnes qui créent leurs propres SVN, mieux c'est, car cela n'améliorera que les options de collaboration à l'avenir (bien que, bien sûr, il serait bénéfique s'il existait peut-être une manière `` standard '' de mettre en place un référentiel scientifique).

- Edit: En fait, j'ai rédigé une telle proposition ici: Stratégie de collaboration scientifique avec LaTeX et SVN . Il propose d'utiliser la fonction svn externals pour permettre une collaboration facile entre des personnes ayant une configuration similaire. Faites-moi savoir si elle doit être modifiée ou n'est tout simplement pas appropriée.

En lisant votre excellent article et en cherchant moi-même une solution, je suis tombé sur l'option de coloriser les modifications au niveau des mots dans gitk . Le paramètre gitk semble être une fonctionnalité nouvelle et / ou non documentée car l'auto-complétion ne le propose pas et la page de manuel gitk ne le répertorie pas.
Voici les options que j'ai trouvées:

gitk --word-diff=plain
gitk --word-diff=porcelain
gitk --word-diff=color

Vous pouvez trouver plusieurs discussions sur ce sujet en recherchant gitk "diff --color-words" .

Edit:
Voici à quoi ça ressemble ...

Je comprends très bien le problème. J'ai commencé à utiliser Kaleidoscope pour diffs avec git. Il est uniquement Mac, mais ses comparaisons fonctionnent mieux que wdiff, et il a également une interface et des mises à jour en direct.