You don't even have to copy them, a link will be enough. It's faster and
doesn't require twice the storage.
--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App ins
If you copy the files, then yes, dt will see them as different. Another
option is to configure your development version to not write sidecar
files (the worse that can happen then is to import a sidecar file
produced by the stable version by mistake).
Owen Mays writes:
> Thanks Mathieu, I hadn't
Thanks Mathieu, I hadn't thought about the sidecars.
It sounds like I should make a sandbox folder, and copy some of my NEF
files into it. Then import them into my testing version of darktable. In
that scenario, darktable will think these are "different" files, right? So
the sidecars for my main i
BTW: not using the same library is one thing, but if you edit the same
photos, one instance of dt will overwrite the sidecar files written by
the other, possibly in an incompatible way (sidecar files written by a
recent version of dt can not always be read by older version).
In short, to be safe:
Thank you Matthieu and Stephane,
I did not know about the :memory: option, that is very interesting.
For most testing I think I'd rather keep a persistent library (so I can
quickly test changes without having to import images again), so I will use
Stephane's suggestion. My "main" darktable instal
Le 29/02/2016 06:50, Owen Mays a écrit :
Hi all,
I'd like to start contributing a bit (looking at bug/feature postings
on the redmine page). Before I try anything, I want to make sure I'm
not going to screw up my darktable install and image library by mistake.
I know I can build a separate v
Owen Mays writes:
> I know I can build a separate version (just specify a different target
> path when I run the build.sh script). But that version is opening the
> same image library as my "main" version of darktable. Is there anyway
> to set up a "sandboxed" version of darktable with its own se
