Metadata storage - let's do this (was: "Tracking file metadata in git -- fix metastore or enhance git?") (was: "Revisiting metadata storage")

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi all,

to summarize the current situation: quite a few people want to have
this, but no one seems to be willing to actually jump into the cold
water and swim.

I decided to scratch my own itch and started to collect requirements,
etc. Obviously, those are mine. I can already tell you that I will
focus on mtime and possibly EXIF support as that is what I need this
whole thing for.
You are very welcome to comment on any of this.


Please note that I decided not to tie this into git but to use a
separate file. The rationale being that, this way, normal git
operations are not impacted in any way and allowing re-use elsewhere.


General:
* Must work with non-git
* Must play nicely with git
** Must merge easily when there are no conflicts
** Must conflict merges if layout version is changed
* No XML as that does not merge
* Assuming I spear-head this effort, it will be in Perl 5
* Possible names include
** metamonger
** metamangler
** git meta
* Needs test suite

Storage:
* Versioned storage layout
* Tab-seperated list (handle file names containing tabs via escaping?)
* UTF-8 for file names, ISO-8859-1 for metadata
* All binary data, if any (support for xattr?) will be ASCII-armoured
* Metadata will be both machine and human readable _and_ explicitly be
designed to facilitate manual editing

Syntax:

$0 save # save metadata, recursively, to .meta.db

$0 apply # apply metadata, recursively, from .meta.db

$0 diff # guess.

-q : quiet
-m : comma-seperated list to override what data will be stored/applied/diffed
-f : specify file name to store to/apply from
-F: store to/apply from .meta.db.$HOSTNAME
-U: store to/apply from .meta.db.$(cat /etc/hostuuid)
--exif-db : EXIF <> db
--exif-file : EXIF <> file

I would like to have this tool be able to operate on EXIF data to see
if the file's mtime and creation time are the same. Very specific use
case, but hey. Maybe factor that out into a cleanly modularized system
and call if via a more generic interface, though


Depending on the feedback I get and how busy I am before christmas, I
may get an initial version up and running before 2012.


If you want to help, nag or anything, please do it asap.


Thanks,
Richard
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]