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

20

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?

soft-question research-practice software writing András Salamon
la source
3
Je ne comprends pas très bien la question. Par exemple, dans SVN, les différences affichées pour un utilisateur sont générées par le client, et cela dépend de votre client SVN (et de sa configuration), que vous obteniez des différences basées sur des mots ou des différences basées sur des lignes. La société qui héberge votre référentiel SVN n'affecte pas cela du tout.
Jukka Suomela
2
@suresh Si vous modifiez des documents texte (écrits), il est souvent difficile de numériser une ligne entière dans un diff pour voir que quelqu'un a changé une virgule. Le comportement correct consiste généralement à montrer l'unité minimale de changement. Ou, considérez le comportement si quelqu'un n'utilise pas les sauts de ligne. Ensuite, changer un seul mot fera apparaître le paragraphe entier dans le diff pour que vous trouviez le petit changement.
Mark Reitblatt
2
Je n'utilise pas de sauts de ligne pour boucler les lignes. Dans mon code source Latex, une ligne de texte physique est généralement un paragraphe de texte complet. L'éditeur peut envelopper le texte pour l'affichage, en fonction de la largeur de la fenêtre actuelle. Cela simplifie beaucoup les choses; il n'y a jamais besoin de s'inquiéter de choses comme si je devais reformater un paragraphe ou convenir de la "bonne" largeur de ligne avec vos co-auteurs. Cependant, vous aurez besoin d'un outil de diff au niveau des mots pour voir les changements rapidement.
Jukka Suomela
2
@Andras Mon point était que le système VC doit seulement être capable de reconstruire les deux révisions côté client, et sans surprise tous les systèmes VC peuvent le faire. Vous avez alors besoin d'un utilitaire de fusion à trois niveaux au niveau des mots, mais je n'en connais aucun. (Par exemple, TortoiseMerge et kdiff3 sont tous deux basés sur la ligne.) Une fois que vous avez un tel utilitaire, alors tout système VC qui vous permet de spécifier un utilitaire de fusion externe suffira. (Cela inclut svn, bzr, git, hg ...)
Maverick Woo
3
Une source de confusion ici est qu'il existe un algorithme de diff binaire intégré (qui fonctionne au niveau des octets individuels) qui est utilisé par SVN dans la communication entre le serveur et le client, et également en interne par le serveur pour conserver le référentiel compact. Ce n'est qu'une optimisation; il n'est pas visible pour l'utilisateur et le même algorithme de diff binaire peut être appliqué à tout type de fichier. Toutes les choses visibles par l'utilisateur (différences lisibles par l'homme, fusion, résolution de conflits ...) se produisent du côté client.
Jukka Suomela

Réponses:

11

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).

Davy Landman
la source
J'envisagerai de le faire pour mes propres documents, cela semble être un moyen facile d'atteindre la plupart de mes objectifs. Mais tout le monde n'a pas envie de travailler de cette façon ...
András Salamon
2
Pour les personnes qui hésitent à travailler de cette façon, vous pouvez utiliser TortoiseGit si elles n'aiment pas la ligne de commande git. S'il s'agit de chaque phrase sur une nouvelle partie de ligne, et tant qu'il n'y a pas de largeur de texte maximale forcée, ce n'est pas si important. (J'ai travaillé sur certains projets sans cette règle)
Davy Landman
Dans l'ensemble, je suis d'accord que git est un bon choix. Mais pourquoi des fichiers séparés pour les (sous-) sections peuvent-ils réduire le nombre de fusions manuelles? Je me demande également comment le fait de commencer chaque phrase sur une nouvelle ligne aide (parfois les phrases se mélangent en cours d'édition).
dd1
en ce qui concerne les fichiers de séparation: à ce moment-là, je ne comprenais pas les détails exacts de la fusion de git, ce qui est en fait inutile, mais toujours conseillé pour d'autres raisons. La phrase sur une nouvelle ligne est très importante, car la plupart des outils autour de git affichent toujours des changements de ligne, si vous utilisez ensuite une autre stratégie, par exemple, laissez l'éditeur faire des sauts de ligne, chaque fois que quelqu'un change 1 mot dans un paragraphe, vous devrez chasser étaient c'est arrivé, et en cas de fusion automatique: pas question.
Davy Landman
4

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.

Noon Silk
la source
4

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 ...

Différences colorées au niveau des mots avec gitk

JJD
la source
1

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.


la source
2
Il me semble que Kaleidoscope n'est qu'un outil de comparaison basé sur des lignes qui, en plus, met en évidence les changements à l'intérieur de chaque ligne. Il ne remplace pas wdiff et ses amis. Le kaléidoscope produit des différences illisibles si vous, par exemple, prenez simplement un paragraphe de texte et modifiez des sauts de ligne. Les outils basés sur Wdiff ignorent simplement les changements dans les sauts de ligne.
Jukka Suomela