Copier des fichiers si le contenu est différent

EDIT : mon premier message n’était vraiment pas clair. Je précise ci-dessous mon souci
:
Il semble que rsync procède comme suit :

  • Il regarde la date de modification de la source. Si elle est plus récente que la cible, il copie le fichier EN ENTIER
  • Il regarde si les tailles des fichiers sont identiques. Si non, il copie le fichier en ENTIER.

Le problème avec le premier point, c’est que si j’ouvre un fichier, je change une lettre, puis revient au point de départ en enregistrant, ou bien si je fais un

touch fichier , rsync va le copier.

Ce que je cherche, c’est une comparaison du contenu du fichier avant une éventuelle copie.
Il existe peut-être un outil déja tout prêt?

Message précédent :
[size=85]Bonjour!
Je cherche un logiciel du même type que git, mercurial ou svn, mais en beaucoup plus simple.
En fait, je ne veux pas garder d’historique de toutes les modifications. J’aimerais simplement pouvoir mettre à jour sur le dépot uniquement les fichiers qui ont été modifiés, sans pouvoir revenir à une branche précédente et cie…

Quelque chose comme rsync, mais qui ne copierais pas parce que le fichier source est plus récent, mais seulement si le contenu de la source est différente de la cible.

Ça existe?[/size]

Plus simple que subversion ça va être compliqué !

En fait le titre est mal posé, car du coup ce n’est plus une gestion de version, puisque je ne veux pas avoir accès aux anciennes versions…

j’ai tenté avec l’option --size-only de rsync, mais ce n’est pas efficace. Si je remplace 1 lettre d’un fichier texte par une autre, la taille du fichier reste la même, et n’est donc pas copié…

je ne l’utilise pas (encore) mais Fossil est présenté pour être simple à utiliser (mais tu auras toujours la fonctionnalité de gestion des versions)

fossil-scm.org/index.html/doc/tr … index.wiki

[quote=“agentsteel”]je ne l’utilise pas (encore) mais Fossil est présenté pour être simple à utiliser (mais tu auras toujours la fonctionnalité de gestion des versions)

fossil-scm.org/index.html/doc/tr … index.wiki[/quote]
Par “simple”, j’entendais minimal :slightly_smiling: . Fossil semble apporter aussi un wiki, possiblité de blog… C’est assez conséquent!

C’est déjà ce que fait rsync lorsque le transfert s’effectue via le réseau. Il fait même encore mieux : il ne copie que les parties du fichier qui ont changé.
Par contre si tu fais un rsync localement ça n’a aucun intérêt d’essayer de voir si le contenu a changé : le temps de vérifier si le contenu a changé (lecture et hashage des deux fichiers), tu aurais déjà fini la copie. :wink:

J’en profite que l’on soit dans pause café mais SVN tu l’utilise couplé à GIT sur ton poste pour profiter des possibilité de granularité de celui-ci ?
Ou tu te cantonne à utiliser uniquement SVN.

rcs ?

http://www.gnu.org/software/rcs/

C’est un gestionnaire de version préhistorique qui pourrait te ravir. Un collègue au taf a mis en place des procédures utilisant ça pour faire du release de fichiers simples (à côté de perforce dans un flow de travail pour les fichiers à livrer). Je suis obligé d’utiliser ça de temps en temps, il faut avouer que ce n’est pas mal.

Les commandes de base :

  • ci = check-in
  • co = check-out
    (je n’utilise que ça…)

Sinon, j’ai l’impression qu’il n’existe qu’un paquet i386 sur les dépôts Wheezy. En espérant que quelqu’un y trouve son bonheur.

Unison ?

Le man de rcs en anglais :
http://www.openbsd.org/cgi-bin/man.cgi?query=rcs&section=1
À regarder les commandes ci et co…

Trouvé via Wikipedia :
http://en.wikipedia.org/wiki/Revision_Control_System

Maintenant je ne sais pas si ça correspond aux spécifications (que je ne comprends guère). Après c’est du gestionnaire de version « plus simple » que SVN. Je ne l’utilise que pour des fichiers uniques au travail, en grattant un peu ça peut peut-être satisfaire au moins une partie des usages. Note importante : il n’y a pas de dépôt à proprement parler, dans l’utilisation que j’en fait : seulement une structure de fichier sur le disque local, un peu « à la .svn ».

Merci pour vos réponses, je vais les étudier au calme.

@syam : Pas exactement. Après des tests, il s’avère que rsync regarde la date de dernière modification. Si la source a une date de modification plus récente que la cible, elle est automatiquement copiée, même si la source a le même contenu que la cible.

Bizarre, ce que tu dis ne correspond pas du tout au man. Enfin si, mais juste en local.
Je répète pour être bien certain qu’il n’y a pas d’ambiguïté : l’algo différentiel de rsync n’est actif que lorsque les transferts se font via réseau (et bien entendu que rsync le sait : par ex. il va pas détecter un point de montage SSHFS/NFS/SAMBA/whatever, il considérera que c’est du local ce qui me paraît tout à fait raisonnable). Par contre en local il copie direct si la date ou la taille ont changé, car c’est plus performant comme ça.

Alors peut-être que je m’y prend tout simplement mal. Voilà la commande que j’utilise vers mon serveur :

De mémoire (mais elle est déjà lamentable à la base, alors aussi tôt un dimanche je te raconte pas…) ça devrait fonctionner correctement pourtant. Je fouinerai dès que je serai moins en vrac et je te tiens au jus.

[quote]Quelque chose comme rsync, mais qui ne copierais pas parce que le fichier source est plus récent, mais seulement si le contenu de la source est différente de la cible.

Ça existe?[/quote]
Oui. Rsync.

$ man rsync

:006

Eh bien je vous assure que non, ça ne fonctionne pas avec rsync.
Il semble que rsync procède comme suit :

  • Il regarde la date de modification de la source. Si elle est plus récente que la cible, il copie le fichier EN ENTIER
  • Il regarde si les tailles des fichiers sont identiques. Si non, il copie le fichier en ENTIER.

Le problème avec le premier point, c’est que si j’ouvre un fichier, je change une lettre, puis revient au point de départ en enregistrant, ou bien si je fais un touch fichier, rsync va le copier.

Ce que je cherche, c’est une comparaison du contenu du fichier avant une éventuelle copie.
Après quelques recherches sur le net, il faudrait vérifier avec md5sums auparavant. Mais avant de me lancer là dedans et réinventer la roue comme on dit, il existe peut-être un outil déja tout prêt?

rsync man :

[quote] --compare-dest=DIR
This option instructs rsync to use DIR on the destination
machine as an additional hierarchy to compare destination files
against doing transfers (if the files are missing in the desti‐
nation directory). If a file is found in DIR that is identical
to the sender’s file, the file will NOT be transferred to the
destination directory. This is useful for creating a sparse
backup of just files that have changed from an earlier backup.

          Beginning in version 2.6.4, multiple --compare-dest  directories
          may  be  provided,  which will cause rsync to search the list in
          the order specified for an exact match.  If  a  match  is  found
          that  differs  only  in attributes, a local copy is made and the
          attributes updated.  If a match is not found, a basis file  from
          one  of  the DIRs will be selected to try to speed up the trans‐
          fer.

          If DIR is a relative path, it is  relative  to  the  destination
          directory.  See also --copy-dest and --link-dest.

[/quote]

Peut-être qu’il faut gratter autour de cette option. J’ai du mal à interpréter le second paragraphe. En tout cas ça ressemble à de la différence en contenu.

J’en profite que l’on soit dans pause café mais SVN tu l’utilise couplé à GIT sur ton poste pour profiter des possibilité de granularité de celui-ci ?
Ou tu te cantonne à utiliser uniquement SVN.[/quote]
Paquet subversion only, un fichier de conf ultra simple un fichier passwd pour les utilisateurs, même pas de daemon a démarrer … ça fonctionne !

J’en profite que l’on soit dans pause café mais SVN tu l’utilise couplé à GIT sur ton poste pour profiter des possibilité de granularité de celui-ci ?
Ou tu te cantonne à utiliser uniquement SVN.[/quote]
Paquet subversion only, un fichier de conf ultra simple un fichier passwd pour les utilisateurs, même pas de daemon a démarrer … ça fonctionne ![/quote]

Yep, effectivement et l’avantage c’est que plus c’est simple plus c’est facile à debug en cas de souci.

Pour ma part j’ai tendance à utiliser GIt sur le poste client couplé à soit du SVN au taff, soit du GIT à la maison.

Les mecs, vous l’avez vraiment lu le manuel ?

[quote]-c, --checksum
Ceci force l’expéditeur à faire une somme de contrôle 128-bit MD4 de tous les fichiers avant le transfert. La somme de contrôle est ensuite explicitement vérifiée à la réception et tous les fichiers du même nom qui existent déjà et ont la même somme de contrôle et la même taille sur le système de réception sont ignorés. Cette option peut être assez lente.[/quote]

Source : delafond.org/traducmanfr/man … ync.1.html

Je rappelle le besoin :

[quote]Ce que je cherche, c’est une comparaison du contenu du fichier avant une éventuelle copie.
Après quelques recherches sur le net, il faudrait vérifier avec md5sums auparavant. Mais avant de me lancer là dedans et réinventer la roue comme on dit, il existe peut-être un outil déja tout prêt?[/quote]
Oui. Rsync. Une fois de plus.
:006

EDIT :

[quote]- Il regarde la date de modification de la source. Si elle est plus récente que la cible, il copie le fichier EN ENTIER

  • Il regarde si les tailles des fichiers sont identiques. Si non, il copie le fichier en ENTIER.[/quote]
    Et bien je t’invite à lire ceci, ça explique plus en détails l’algorithme (sans non plus entrer dans des choses trop techniques) : rsync.samba.org/how-rsync-works.html
    En gros, les fichiers sont découpés et “rsync” calcule le checksum de chaque partie. “diff” intervient également pour essayer de trouver plus facilement les parties identiques. Au final seules les parties différentes sont envoyées. C’est un algorithme assez complexe, je n’ai pas encore trouvé d’explications complètes détaillées à ce sujet (j’ai pas trop cherché non plus faut dire).

EDIT 2 :
Le site officiel donne l’algorithme de manière assez simple : rsync.samba.org/tech_report/node2.html
Notamment :

Soit en français :

Le résultat final est que Beta obtient une copie de A, mais seuls les morceaux de A qui n'ont pas été trouvé dans B (plus une petite quantité de données pour les checksums et les indexs des blocks) sont envoyés sur la liaison.

Est-ce que ça répond à toutes tes questions ? :wink:

EDIT 3 : donc au final “rsync” peut tout à fait faire ce que tu souhaites, il suffit de bien le configurer ce qui, je le conçois, n’est pas toujours une sinécure.