> A mon avis, c'est typiquement ce qu'il ne faut pas faire : réinventer la roue.
Oui.
> Ce que tu viens de décrire doit être en gros ce que fait rsync.
Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.
Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.
[^] # Re: Variation
Posté par Matthieu Moy (site web personnel) . En réponse au journal Considération sur l'emploi de rsync. Évalué à 1.
Oui.
> Ce que tu viens de décrire doit être en gros ce que fait rsync.
Pas tout à fait. La difficulté de rsync, c'est qu'il ne veut envoyer que le patch, mais que pour calculer le diff correctement, il faudrait avoir les deux copies sur la même machine, et ça, justement, c'est ce qu'on cherche à faire. Du coup, rsync se débrouille en coupant le fichier en morceaux, envoyant les checksums des différents bouts, ... mais c'est quand même sous-optimal.
Une solution qui fait des diffs en local, et qui envoie le patch, ça existe déjà aussi, c'est ce que fait à peu près n'importe quel gestionnaire de versions. Donc, une solution assez simple serait d'utiliser par exemple Git, un commit sur la machine distante, un "pull" et le tour est joué.