Image clonées et synchronisation

[aurelienpierre]

Tes fichiers ne sont pas synchronisés entre différents PC, ils sont synchronisés entre les PC (hôtes) et le stockage centralisé distant (serveur, qui peut être un simple disque externe, un NAS, un espace de cloud…).

Le schéma est le suivant :
Sur poste A :
1. au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
2. compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
3. Si ajout de nouvelles photos, utiliser le serveur comme répertoire de base
4. télécharger une copie locale des photos à retoucher
5. retoucher (depuis la copie locale, mais c'est transparent)
6. resynchroniser la copie locale vers le serveur à la fin de la retouche.

Sur poste B:
1. au démarrage du logiciel, vérifie la version du XMP serveur des fichiers dans la BDD locale.
2. compare avec la version hôte
a) si versions différentes, demande dans quelle direction synchroniser
b) sinon, passer à 3)
3. Si réutilisation des photos importées depuis A, réimporter le dossier/la pellicule dans la base de données locale de B (c'est la partie pénible).
4. télécharger une copie locale des photos à retoucher
5. retoucher (depuis la copie locale, mais c'est transparent)
6. resynchroniser la copie locale vers le serveur à la fin de la retouche.

Synchroniser entre les PC en court-circuitant le serveur me paraît tendu :
1. darktable ne sait pas le faire, ce qui suppose passer par une synchronisation bidirectionnelle par un outil externe… qui ne sait pas comment dt est structuré. Donc il copie à l'aveugle la version la plus récente sans vérifier la compatibilité des modifications (l'équivalent d'un diff sous git). Donc à la fin c'est la surprise du chef sur ce que tu vas trouver, surtout si tu fais des retouches à moitié sur un ordi, puis rouvre la photo sur un autre… Comment on gère les versions en conflit ?
2. ça suppose d'avoir autant de copies des images que de postes… à voir si c'est rationnel.
3. faire transiter des RAW sur le réseau en permanence (sans backup) augmente le risque de corruptions de données. Moi j'ai des RAW de 2009 illisibles aujourd'hui, après 3 changements de disque dur, à cause des corruptions. Pour cette raison, une version maîtresse versionnée/sauvegardée qu'on ne touche pas me semble plus sécuritaire à long terme.

L'avantage de la copie locale est que l'étape de lecture et l'étape d'écriture sur le serveur sont différées : en cas de corruption au passage dans le réseau, tu peux récupérer un version intègre dans le dernier poste utilisé. Sans copie locale, tu lis/écris en temps réel à travers le réseau. En cas de souci réseau, darktable ne vérifie pas l'intégrité des fichiers transmis et ne les sauvegarde pas.

Les RAW serveur sont en lecture seule. La resynchronisation d'une copie locale devient alors l'équivalent d'un commit push sur le XMP. Ça demande plus de vérification humaines, mais c'est moins de pleurs en cas de pépin.

Je pense qu'il n'y a pas moyen de jouer au plus fin avec dt en faisant de la sychronisation automatique externe, il faudrait l'introduire en interne dans dt avec des diffs sur les entrées XMP pour valider les modules au cas par cas sur conflit de versions, et un versionnage locale et distant. sinon, on fait le même genre d'horreur que dropbox où tout est synchronisé de façon bidirectionnelle, et il faut appeler tes collaborateurs pour leur dire de ne pas éditer les fichiers partagés pendant que tu bosses dessus.