Hello Owen, On Sat, Dec 14, 2019 at 7:02 PM Owen Mays <r.owen.m...@gmail.com> wrote:
> > 2) Since sharing the library is not recommended, is there a recommended > way to have one computer be aware of edits made on/by another computer? The > problem I'm trying to solve is: my photos live on my laptop and are usually > imported and edited there. For large jobs, I would like to be able to do > processing on my desktop, which has a GPU. My current solution is to mount > my laptop harddrive on the desktop via sshfs and point both darktable > instances to a library file in the shared folder. > I solved this dilemma using git, or more specifically git-annex. Darktable keeps everything in XMP sidecar files which make the database redundant. For sharing the edits between my laptop and my desktop pc I have everything under version control (including darktable's db, settings, rc-file, etc). I run darktable using the `--library :memory:` switch, which causes dt not to write to the db. Using git-annex makes it simple to transfer RAW files between computers, usb drives and storage devices. Drawback: If you edit two pictures without updating your working copies first you might run into a merge problem which is probably not easy to solve given the XML structure. However, you can always create a copy of the XMP and compare. Otoh, you can edit different images on your computers and merge those back easily. It does require a bit of discipline and knowledge about version control, but in the long run it pays off. I manage my collection of images pretty successful with this approach. Cheers, Jochen > 3) Is there any risk to the database in doing this, provided I avoid > having multiple darktable instances accessing the database at once? (For > instance, the bash script I have that launches darktable and points it at > the shared folder could also check for the existence of the lockfile and > respect it). > > Thanks, > Owen > > On Sat, Dec 14, 2019 at 3:08 AM Sturm Flut <sturmf...@lieberbiber.de> > wrote: > >> Hi Owen, >> >> the locking mechanism could probably be extended to also include the >> hostname in the lockfile. >> >> The problem with putting SQLite databases on a network share is that >> it's discouraged by SQLite [1] to begin with because too many things can >> go wrong. If darktable's locking mechanism fails for any reason, you >> might end up with two darktable instances on two difference machines >> accessing your database and corrupting it. >> >> cheers, >> Simon >> >> >> [1] https://www.sqlite.org/faq.html#q5 >> >> >> On 14.12.19 09:42, Owen Mays wrote: >> > Hello Darktable Devs, >> > >> > First of all, thanks for a fantastic program! >> > >> > I'm attempting to share a darktable library between two computers >> (using >> > the same network storage), and I'm concerned about accidentally >> > corrupting the database. Darktable creates a lock file, but when I >> > launch darktable on the second computer, it just overwrites the lock >> file. >> > >> > It appears this is due to logic in the database.c file that checks >> > whether the PID in the lockfile belongs to an active process. Because >> > the lockfile was created by a process on another computer, darktable >> > thinks the lockfile is stale and overwrites it. >> > >> > Is there a reason the lockfile is not more strict? Why go to the effort >> > of checking the PID, why not assume the lockfile means a lock, and if >> > it's stale, leave it to the user to resolve? >> > >> > I can create a bash script wrapper to launch darktable that will first >> > check for the lockfile, but I'd like to understand the design decision. >> > >> > Thanks, >> > Owen >> > >> > >> ___________________________________________________________________________ >> > darktable developer mailing list to unsubscribe send a mail to >> > darktable-dev+unsubscr...@lists.darktable.org >> > > ___________________________________________________________________________ > darktable developer mailing list to unsubscribe send a mail to > darktable-dev+unsubscr...@lists.darktable.org > ___________________________________________________________________________ darktable developer mailing list to unsubscribe send a mail to darktable-dev+unsubscr...@lists.darktable.org
