how do I know GIT "really" needs a new library.db

solved
#1

Hi everybody,

I hope this question is not too silly…

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. :smile: 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 :blush: )

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

Thanks in advance
Cheers
Axel

(Jim Robinson) #2

Axel,

If you had subscribed to the user mailing list you would have seen the significant change to the database announced there. See:

https://www.mail-archive.com/darktable-user@lists.darktable.org/

cheers,

Jim

#3

Dear Jim,

I see, I was too selfish enjoy new things without the full commitment when I step into the dev-branch :wink:

Cheers
Axel

(Pascal Obry) #4

Well dev/master branch is what it is. Do not use it if you are not ready to have issues :slight_smile:

Frankly I don’t see what I could have done better with all the announcements.

#5

Dear Pascal,

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 :slight_smile:

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 :smile:

Yet again, I admit, when I step in a foreign garden, I should study the local rules better beforehand :wink:

Cheers
Axel (a Harry Durgin-“student” :smile: (I just like that guy a lot) )

(Pascal Obry) #6

Good idea! And done.

Capture%20d%E2%80%99%C3%A9cran%20de%202019-03-08%2023-30-45

5 Likes
#7

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 :smile:

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]”

Cheers
Axel

#8

Another question just because a non-dev-guy dares to use git-master :slight_smile:

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 ?

I could bear it, just wanna know…

Thanks in advance
Cheers Axel

(Mica) #9

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.

#10

But I did quite some edits with git-master and actually wanted to get them in my 2.6.2 library via the xmp-files :slight_smile:

Maybe I was spoiled by the situation, 2.4.x and 2.5 lived well in parallel for quite some time.

(Mica) #11

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.

2 Likes
(Pascal Obry) #12

That’s not possible! How could 2.6.2 know how to use an xmp for a module that is only on master?

#13

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… :slight_smile: