A short story. For years I've not only accumulated thousands of pictures[^1] (around 50,
to be more precise) but also schemas on how to sort those photos. After a long internal
debate, I settled for the following one (for the moment, that is):

* Pictures are imported from the camera's SD via a script, which:
  * Renames them from `DSCXXXXX.JPG` to a date based file name, using the picture's
    exif data.
  * (Hard) links them to a year/month based dir structure.
* Later, pictures are sorted by hand into thematic dirs for filtering.
* The year/month tree is handled with `digikam` for tagging.
* Pictures are filtered into their final destination sorted by category, year and
  event (for instance, `trip/year/to_this_place`).
* Pictures are also (hard) linked into a tag based dir structure, using nested tags.

So, the whole workflow is:

    SD card --> incoming/01-tmp -> incoming/02-new/theme -> incoming/03-cur --> final destination
            `-> year/month                                                  `-> tags/theme/parent/child

The reason for using hard links is the following: I `rsync` everything to my home
server, both as backup and for feeding the gallery(s) there. Because pictures are
moved from one location to another until they reach their final destination, `rsync`
retransmits the picture in its new location and then deletes the old one (I'm using
`--delete-after`, to make sure the backup does not loose any picture if the transfer
is stopped). This leads to useless transfers, as the picture is in the remote.

I played with the idea of using `git` or even `git-annex` for working around this,
but in the end I decided to (ab)use `rsync`'s hard link support. Now moving any picture
in the workflow or renaming a category, theme or directory just means creating new hardlinks to the links in the year/month tree
and removing the old ones later, an almost immediate operation. This also helps saving
space and time when implementing the tag based tree.

`digikam` is good enough to uniquely identify each picture, even when two hard links
point to the same file. This still means the picture appears several times; the
metadata (most importantly, tags) are shared, but each new link
adds load to the `digikam`'s database.

I bit the bullet and sat down to do a last move and be done. I moved the year/month
tree to `ByDate/`, completely isolating it from the rest of the collection. Then pointed
`digikam` to only read that, and here's how I did it:

* Closed `digikam`, of course.
* Backed up everything, including both the database, which was in the collection's root, and the
  `.local/share/config/digikamrc` file.
* Modified the latter so it points to the new database location:

```ini
[Database Settings]
Database Name=/home/mdione/Pictures/ByDate/
Database Name Thumbnails=/home/mdione/Pictures/ByDate/
```

* Moved the database.
* Changed the collection's root dir in the database:

```sql
mdione@diablo:~/Pictures/ByDate$ sqlite3 digikam4.db
-- Notice the specificPath is relative to the volume. In my case, the volume is /home
sqlite> select * from AlbumRoots;
1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures
sqlite> update AlbumRoots set specificPath = '/mdione/Pictures/ByDate' where id = 1;
sqlite> select * from AlbumRoots;
1|Pictures|0|1|volumeid:?uuid=f5cadc44-6324-466c-8a99-4ede7457677e|/mdione/Pictures/ByDate
```

* Fired `digikam` and let it rescan the collection, which recognized the only link
  to the image and kept the tags.

This worked superbly!

[^1]: When I talk about pictures, I'm also including videos.