[Top][All Lists]

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

Re: [Gnu-arch-users] Re: arch with 'special files'

From: Josh England
Subject: Re: [Gnu-arch-users] Re: arch with 'special files'
Date: Thu, 07 Apr 2005 09:39:40 -0700
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050329)

Jan Hudec wrote:
> On Wed, Apr 06, 2005 at 13:36:14 -0700, Tom Lord wrote:
>>   > A single 'second-order' metadata string would basically give infinite
>>   > flexibility in terms of metadata. [...] would
>>   > allow any number of creative facilities to be built on top of it.
>>A unique fixed string per file would have the same effect and we
>>already have one of those.

I understand what you're getting at.  One could archive their own
metadata file(s) indexed by the file ID, then manage the metadata in
surrounding wrappers.  This actually does effectievly allow generic
metadata to be created.  Perhaps explicitly adding it to arch is not
necessary.  Maybe just detailing how this could work in the
documentation would be enough.

However, providing a fast/formal/consistent indexing method would also
be nice, that way the metadata is always in the same place instead of
being different in every archive.  A fast indexer could effeciently be
used to power a 'tla get-changed-metadata' command to return a list of
all files with changed metadata.  Then, 'tla get-metadata <file-id>' and
'tla set-metadata <file-id> <meta-string | meta-file>' or some such
could be used to get/set the actual metadata per file-id.
I think this might be converging on something that doesn't suck.

> Yes, but we need one more -- the id must not change throughtout life of
> the file, while other metadata may need to change. So we need an id and
> another string. That is two strings so we can as well have N strings
> (we'd need a _standard_ way to mangle N attributes in it anyway).
> They should probably live somewhere in {arch}, indexed by file id's.
> We calso need a way of passing them into a hook to process them. There
> should be one hook when preparing a changeset (so it can synchronize
> with attributes saved by some other means) and one when applying
> a changeset (so it can apply them).

In looking at Monotone, they seem to have the ability to call per-file
metadata hooks:

This kind of thing probably wouldn't be too hard to add in to the
proposed solution above...


reply via email to

[Prev in Thread] Current Thread [Next in Thread]