mirrors/git-annex
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages 1 Wiki Activity Actions

thoughrs

Browse source
This commit is contained in:
Joey Hess 2018-04-04 12:50:09 -04:00
parent c14638886f
commit c6252018fa
No known key found for this signature in database
GPG key ID: DB12DB0FF05F8F38
1 changed files with 30 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

30
doc/bugs/file_modification_time_should_be_stored_in_exactly_one_metadata_field/comment_2_32285971869ec56460b3f0eee4edfa23._comment Normal file
View file

@ -0,0 +1,30 @@
[[!comment format=mdwn
username="joey"
subject="""comment 2"""
date="2018-04-04T16:40:19Z"
content="""
One use case for the separate fields is `git-annex view`,
where they allow creating view branches with yyyy/mm/ subdirectories
or artist/yyyy/ or whatever kind of thing the user wants.
Part of the original metadata design, which never got implemented,
was to allow pure functions on metadata, that added to the set of available
metadata. So a unix timestamp could be what's stored in metadata, and then
the individual fields (and more fields that are currently omitted to avoid
bloat) derived from it.
I'd be happy to see that part of the metadata design actually happen.
There are some potential problems with it that need to be thought about,
such as:
* What should happen if the user runs `git annex metadata` to change
or delete such a derived metadata field?
* If a unix timestamp is stored, it's harder for the user to make
some simple edit, such as adjusting the year of a file to the year they
want. Should a change to a derived year field propigate back to the unix
timestamp? (Would need reversible functions.)
(BTW, the timestamps on metadata fields come for "free" in that the
underlying metadata storage log necessarily contains timestamps of when
each part of the metadata was changed.)
"""]]