For redmine to be read-only for everybody you’d have to disable insert/update permissions on database to redmine-database user… or create new user with disabled permissions so it’s tricky.
I don’t have redmine account and it cannot be created (which is good, because no new people will join) but if somebody with access has time, it would be good to advertise github all over the redmine, move articles from redmine to github wiki and then disable insert/update to redmine database
As for issues themselves - there are at least 13 new issues since 3.0.0 release (10 since 01.01.2020) and over 200+ modified since 01.01.2019… many seem to be not present in github (or are since closed) so checking on them & closing (or just mass flood reply “post issue to github if you can replicate it on darktable master”+close) would be good overall.
Ultimatelly redmine.darktable.org should just redirect to github (once move is complete).
I’d been overlooking something obvious. I’d built my new multi-year library starting with my 2020 darktable library and adding my earlier 2016–2019 photos (they all have xml sidecar files from their previous darktable libraries). As part of this, I also then moved all my 2020 photos from an external hard drive onto one of my laptop’s drives. I used the “search filmroll” in darktable to tell it where these photos had moved to.
And then I started using darktable by importing in a backlog of newer photos in my New downloads folder on my computer. It turns out that it was only these newer photos that I was seeing in my 2020 folder on darktable.
The trick is that these newly imported 2020 photos showed up in darktable with a different file path to the older 2020 photos that I’d relocated onto my laptop with “search filmroll”. The newly added photos are all in /Users/jonsullivan/Pictures/Darktable/Photos/2020/… while all of my other 2020 photos were in /Volumes/Morus/Users/jonsullivan/Pictures/Darktable/Photos/2020/… Note that this is exactly the same folder.
Embarrassingly, I’ve got the “Volumes” part of folders view collapsed in the screenshot I posted and I hadn’t noticed until today that it contained my other 2020 photos as well as my photos from earlier years.
Interestingly, if I add some of those older 2020 photos onto darktable again (by dragging a folder on to the darktable icon in the Mac dock), they end up being duplicated in darktable, by being added to /Users/jonsullivan/Pictures/Darktable/Photos/2020/… while also still being present in /Volumes/Morus/Users/jonsullivan/Pictures/Darktable/Photos/2020/… (even though that’s the same place on my drive).
My solution was to add all of my 2020 photos again, dragging them onto darktable, so that they are all together with my more recent photos in /Users/jonsullivan/Pictures/Darktable/Photos/2020/… I then went to /Volumes/Morus/Users/jonsullivan/Pictures/Darktable/Photos/2020/… and selected all the photos and removed them from darktable.
This does seem to have revealed an odd quirk in darktable 3, at least on Mac.
I drag photos from my Pictures folder onto the darktable icon in the dock, and they end up with full path /Users/jonsullivan/Pictures/…
Once I’ve tagged them up, I use the move… tool inside darktable to move them to another folder in Pictures, but then they end up with full path /Volumes/Morus/Users/jonsullivan/Pictures/… (where Morus is my main laptop hard drive).
So they end up in different parts of the folders view. I have to use other ways (like date) to view my recently imported and tagged photos in the same lighttable view.
I think this is a darktable 3 thing, as I didn’t run into this before 3.0 and my workflow is the same.
This looks more like Mac lying about paths. I mean - if /Users/jon is same as /Volumes/Morus/Users/jon and Mac sends first when doing query and second when doing image operations, the app has little chance of knowing that they are identical without some additional checking.
