On Tue, Sep 14, 2010 at 02:03:57PM +0300, Take wrote: > > That's one usage model. In my case I like to sync files to my laptop using > > "unison" - I have fast off-line access to them, and it acts as a backup. > > Well, this could be taken care of with the 'root folder' -setting I > mentioned in previous post. This way you could sync images to $anywhere > and set that rootdir properly and, since information in database would > be related to that rootdir, you could access your files in the same way > regardless of the machine. > > Of course you need to maintain sync for database, but with sqlite that's > fairly simple
It is? How?? 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). 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) In any case, coming from a Unix background, of small tools and open data, I'm uncomfortable with the database approach. Sure, it's fast to access, but it's (a) monolithic, (b) fragile, and (c) closed (in as much as you need to reverse engineer to get at your work) 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 catastrophic. But if a single-file sqlite3 database becomes corrupt, and I don't happen to have an up-to-date backup, then everything is lost. Hmm, I guess I'm talking myself into using gthumb again. It's a shame, as there's a lot of things I like about shotwell's UI, such as being able to browse events with a representative title photo on each one. Regards, Brian. _______________________________________________ Shotwell mailing list [email protected] http://lists.yorba.org/cgi-bin/mailman/listinfo/shotwell
