Le dimanche 26 juillet 2015 à 14:45 +0200, Stefan Klinger a écrit : > Hi there, > > as a newbie I'm trying to experiment a lot with what DT can do. > However, I find it hard to not accidentally destroy a history stack > that turns out well, or that I want to consider "fixed" because I have > ordered a print of it. Unfortunately, DT is rather trigger-happy when > destroying an existing history stack. > > Currently I have resorted to write-protecting the XMP-file (IMHO > that's "the right thing"™ to do), but which is semi-ignored by > darktable. DT will not write to the XMP anymore (which is good), but > modify the database to store further changes. These are displayed and > used from then on. > > There is an "updated xmp sidecar files found"-dialogue, but that > > * only shows up if the timestamp of the XMP is *newer* (as opposed > to "different") than what DT's database knows. > > * It does not show up when database and XMP differ, but the XMP is > "older" than the database knowledge. > > Hence, write-protecting a file will allow the database version of an > image divert from the XMP file, accumulating more and more edits, > without the user even noticing. A backup of the XMP then reflects an > outdated version. > > I have filed a feature request [1], but I'm getting the feeling that > I'm the only one having this problem.
How do you guys make sure that you will never accidentally destroy a particular history stack? particular history stack == exported jpg file As, i have automatic backup of my raw & my jpeg (exported from DT) & jpag file have the history stack, it's does the job nicely ;) Regards > > Thank you > Stefan > > ____________________ > [1] http://redmine.darktable.org/issues/10532 > > ------------------------------------------------------------------------------ _______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
