I remember in 2018 for quite long time I could use git-version and the official branch in parallel.
Which was nice, when you know, what you are doing…
Somehow near August 2018 it was then the time, the official branch didn’t want to accept the library any more and I was fine, as git was proven stable for my use case.
Now this happened already in early March. I know it’s documented but late at night I would have needed a red blinking stopsign at start-up. Good to have a backup-NAS (and btw. close dt when you go to sleep, or you have a locked library.db in the backup folder, which cannot be imported )
Besides RTFM, is there a cool way to realize before start, it’s time to change the library.db?
BTW: I do the git pull with a simple bash-script
please! Do not think, one ask you to do something better. I saw your post now and your comment also is perfectly right, one have to be ready to face issues… I admitted already, that I should have committed more comprehensively
Just aside… is there a chance to detect automatically by software, that is is about to update library.db to the next level upon start-up and warn the use by a prominent pop.up with the chance to cancle (or auto-backup library.db with a date-tag? For those non-coders who dare to take the bet “ready to have issues”, it would be a great help
Yet again, I admit, when I step in a foreign garden, I should study the local rules better beforehand
Cheers
Axel (a Harry Durgin-“student” (I just like that guy a lot) )
Cool !
I tried already, I think this really makes it more safe for guys like me. Who is on the front edge, never needs it, that’s clear.
Actually it can remain for the official branch as well and then becomes a x-mas gift
I have another one. If a “WARNING” is as critical as the recent one, would it make sense to paste it here or have a link to the mailing list at least, just like:
“For latest information about changes to dt check the developers mailing list: [link]”
Another question just because a non-dev-guy dares to use git-master
I did save my ~/.config/darktable and ran git-master. It is nice, especially I like the GUI updates of blend modes.
However, I have my reasons, I want to go back to 2.6.2. So I moved back my old 2.6.2 config-folder and upon darktable’s opening I get asked and confirmed to import the xmp-files of the recent edits to the library. But I get (bunch of):
error: Xmp schema version 3 in /home/gerber/Bilder/2018/20180520_Madagaskar/16.05.18/2018-05-16_155034_AG7_9976.NEF.xmp not supported
I know… I maybe should have participated the mailinglist, as Jim said above. Even I had a quick glance, I cannot really find the topic. Now I have to stay until the next version is compatible to the current xmp-scheme-Version3 ?
The XMP files from darktable are not backward compatible across major versions, either, as far as I know. Either restore from a backup, or accept the import errors.
I keep my XMP files in a got reposo that I can always roll back.
Another solution would be to set your git version of darktable to not write XMP files.
I don’t think it works that way. Hopefully with the darktable team shifting to more regular releases, we won’t have to wait for features for so long and situations like this will be less likely yo arrise.
Yes, I’d say that was a happy coincidence and you should not expect it to work that way moving forward.
Got it
I thought, in such case, those would be simply ignored…
As I said, I got it and was over-spoiled, that during my first approach to master, by chance it was for quite some period of time compatible to each other…
Good to have a backup-NAS (and btw. close dt when you go to sleep, or you have a locked library.db in the backup folder, which cannot be imported 
)
