On 09/14/2010 09:23 PM, Brian Candler wrote: > I could 'unison' the underlying sqlite3 db file - but a single conflicting > change made at both sides would cause all subsequent replication to fail, > until I decided which side wins (which would lose all changes made at the > other side).
Sorry, my bad, I just tought of the file sync, not the content, so, you're right, it's not simpe with sqlite. With i.e. MySQL that's whole another matter since it's possible to store binlog and sync changes step-by-step, but that's not really simple to set up. > Otherwise, I can't see how you could do it without writing a > Shotwell-specific replicator, and adding further columns or tables into the > database schema to support conflict resolution (e.g. history of changes) How about an a bit different approach. Use separate XMP-files and run some small(ish) version control (ie. RCS) with them. Then one could (possibly) sync metadata via that version control and diff-patch(-ish) -procedure. Actual photos would sync as plain files, so rsync or derivatives can take care of that. Separate metadata files however raise more questions, like how to index them for faster search. > but it's (a) monolithic, (b) fragile, and (c) closed (in as much as you need > to reverse engineer to get at your work) I don't want to store my photos into database either, just the metadata. There's absolutely no sense to push actual files into database for obvious reasons (I like to access my files with file browser, not with database "browser"). > If metadata is stored in separate XMP files, or within the JPEGs (I don't > mind which), then loss or corruption of an individual file is not If metadata is stored to images, it'll require an image format which supports it. Even if there's a wide range of formats it's not supported in every format, so my "vote" goes to separate files with this approach. With separate XMP files it might even be possible to migrate changes on conflict situations. -- Take _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
