- Facile à maîtriser et utiliser ;
- Léger ;
- Bonne tenue en charge (« scalabilité ») ;
- Facile à personnaliser.
Laissez-vous tenter par cet excellent outil qui ne pêche que par le manque de publicité qu'il génère face à Bazaar ou Git.
![[en]](../images/en.png)
L'annonce de la 1.0 (367 hits)-
Homepage (856 hits)
-
Téléchargement (153 hits)
-
La documentation (306 hits)
-
La naissance du projet (189 hits)
> Lire la dépêche (36 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #916417.
Run by 
Cette page a été générée par Templeet en 0.0806s (dont 0.0075 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
plugins ODT ?
Existe-t-il des gestionnaires de version qui supportent l'ODT ?
De manière générale, ce serait cool d'avoir des gestionnaires avec des plugins en fonction des type de fichier. Cela permettrait par exemple de gérer les diffs entre des images et ce genre de choses.
[^]Re: plugins ODT ?
Pour l'odt, c'est du texte (xml) donc, il ne doit pas avoir de problèmes.
Pour les images, il y a des formats de fichiers qui retiennent l'historique des changements...
[^]Re: plugins ODT ?
Non, c'est du xml compressé en zip. Ce n'est pas la même chose.
[^]Re: plugins ODT ?
Et c'est du XML "tout-sur-une-ligne", donc un diff bête et méchant dessus ne fait pas grand chose d'intéressant.
[^]Re: plugins ODT ?
Il est possible d'enregistrer les fichiers ODT/XML avec des retour-chariots.
Il suffit d'aller dans :
menu Outils > Options > Chargement/Enregistrement > GénéralDécoche ensuite :
Optimisation de la taille pour le format XML.[^]Re: plugins ODT ?
Ca change vraiment la taille leur truc ? Surtout si ils compressent le fichier apres...
[^]Re: plugins ODT ?
Personnellement, je ne sauvegarde jamais avec l'optimisation et je n'ai constaté aucune augmentation significative de la taille des fichiers.
Effectivement, la compression atténue grandement une augmentation déjà peu importante en elle-même.
[^]Re: plugins ODT ?
Probablement avec ça
http://hgbook.red-bean.com/hgbookch10.html#x14-19700010
Un
gzip sur le fichier + un 's/></>\n</g' devrait faire l'affaire.
Pour le faire proprement, il faudrait un diff qui fonctionne sur une arborescence (et pas sur les lignes). Mais bon, qui se propose de le faire car c'est un Gruiik-Gruiik ce genre de chose ? Un algo LCS (Longest Common Sequence) est vraiment simple par rapport à ça.
La bonne question est cela vaut-il vraiment la peine de se crever à créer un utilitaire diff pour chaque type de fichier existant ? Traitons-les juste comme du binaire ou utilisons des formats adaptés.
Pour ma part, c'est du LaTeX, donc, jamais eu ce type de problèmes.
[^]Re: plugins ODT ?
La bonne question est cela vaut-il vraiment la peine de se crever à créer un utilitaire diff pour chaque type de fichier existant ? Traitons-les juste comme du binaire ou utilisons des formats adaptés.
La réponse est ... oui.
Chaque format de fichier dispose de sa propre sémantique et ce n'est pas parce que tu disposes de comparateur/merger de fichiers XML que tu es en mesures d'apprécier un même changement qui apparait en plusieurs endroits d'un même fichier.Il y a de réels risques de corruption de fichiers.
Clearcase implémente ca depuis toujours en permetttant d'associer à chaque type de fichier de se voir associer un outil de comparaison/fusion adapté. Malgré tous ses défauts, la façon dont il aborde cette problématique reste un de ses principaux attraits par rapport à la concurrence.
Ainsi tu peux comparer des fichiers Word graphiquement (en attendant ODT) mais aussi des fichiers Rose ou même des arborescence complètes.
Des initiatives émergent pour proposer des comparateurs pour les types de formats qui soient indépendantes du gestionnaire de version (cf. EMF Compare par exemple http://www.eclipse.org/modeling/emft/?project=compare#compar(...) Il serait donc dommage que les VCS ou les outils clients le négligent.
ODT ne devrait donc pas déroger à la règle et proposer lui-même cette fonctionnalité (plugin OpenOffice par exemple).
[^]Re: plugins ODT ?
>Chaque format de fichier dispose de sa propre sémantique
Ce que je veux dire c'est que justement cette sémantique n'est pas si évidente. Cela semble simple sur papier, mais comparer des fichiers n'est pas trivial voire complètement voué à l'échec.
Quelques exemples :
- Prenons 2 images dont la différence est juste un correction de luminosité : comment faire un diff (tous les points ont changés) ?
- Prenons 2 fichiers xml dont la différence est
<it>Italics</it> devient <it>Ita<bd>li</bd>cs</it>
Le texte est le même mais la présentation pas que sort le diff ?
- Prenons 2 fichiers xml
<item>item1</item>
<item>item2</item>
et
<item>item2</item>
<item>item1</item>
Sont-ils identiques ou pas si l'ordre n'a pas d'importance ?
Et encore, j'ai choisi des cas extrêments simple. Dans des cas rééls, je n'ose même pas imaginer les problèmes possible.
[^]Re: plugins ODT ?
Et ma réponse est donc.
Qui connait le mieux la sémantique de son fichier que l'outil qui l'exploite ?
L'outil doit fournir son propre comparateur/mergeur qui accepte en paramètre 2 (comparaison) ou 4 (merge 3 contributeurs) versions de fichiers selon que tu souhaites comparer ou merger.
Dans ton cas, il présente graphiquement la différence, te propose de choisir la combinaison et il assure la cohérence du changement. Le cas du merge des fichiers texte à plat (sources) qui ne présument pas de la sémantique n'est qu'un cas particulier. Pourquoi vouloir le généraliser à tous types de fichiers.
Ainsi même un fichier java a une sémantique différente d'un fichier python et si un outil VCS les traite de façon identique on peut très bien imaginer qu'il passe la main à un IDE qui connait mieux la structure de ce fichier et est capable d'apporter plus d'intégration tout en n'étant pas trop intrusif (par exemple l'ajout d'une accolade ouvrante dans un merge de .java s'accompagne forcément de l'ajout d'une accolade fermante pour marquer la mise en bloc). L'IDE en est capable. encore faut il que le VCS lui passe la main dans de bonnes conditions.
Ainsi on reste indépendant de l'outil VCS pour peu qu'il respecte le protocole.
A chacun ses responsabilités.
C'est ce que j'attends d'ODF (mais peut-être qu'OpenOffice le propose déjà)
[^]Re: plugins ODT ?
Non seulement c'est du XML compressé en ZIP, mais si tu lis couramment le XML des documents OpenOffice.org, moi pas. Je ne me vois pas faire un diff entre deux versions d'un même document pour savoir ce que j'ai pu modifier.
Ce qui manque dans tous les VCS, c'est un outil de diff pour les ODT, point.
[^]Re: plugins ODT ?
un truc comme ca?
http://extensions.services.openoffice.org/project/OOoSVN
(par contre on dirait que cela n'est plus trop developpe...)
[^]Re: plugins ODT ?
En suivant quelques liens il semble que le projet soit devenu : http://odfsvn.sourceforge.net/
[^]Re: plugins ODT ?
D'après ce qui est dit juste au dessus, il est apparemment possible d'utiliser des filtres avant et après le diff.
Utilise alors un filtre ZIP/UNZIP pour le type ODT et le tour est joué.
C# (sans runtime) + GObject = Vala
[^]Re: plugins ODT ?
Mercurial (Hg) supporte l'ODT, et donne ici une astuce pour afficher les diffs :
http://www.selenic.com/mercurial/wiki/index.cgi/HandlingOpen(...)
[^]Re: plugins ODT ?
http://www-verimag.imag.fr/~moy/opendocument/
(même texte que celui cité plus bas sur le Wiki de Mercurial)
En fait, à partir du moment où on a un truc un peu flexible, et qu'on connait odt2txt, c'est assez facile de générer des diffs sur ces fichiers.
Par contre, c'est un diff visuel, mais hors de question de l'appliquer avec patch. Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.
[^]Re: plugins ODT ?
Plus généralement, je ne crois pas qu'il existe de bons outils de merge sur ce genre de fichiers.
Il y a http://tdm.berlios.de/3dm/doc/index.html
C'est un peu rugueux... Mais j'espère bien l'utiliser ou m'en inspirer à court ou moyen terme (comprendre, dans longtemps ou jamais.... vu l'état d'avancement de mes projets perso)