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

[Josh England]

Robert Widhopf-Fenk wrote:
> On Wednesday, March 30, 2005 at 12:19:39, address@hidden wrote:
> 
>>On Tue, Mar 29, 2005 at 11:39:04AM -0600, John Meinel wrote:
>>
>>>Josh England wrote:
>>>
>>>
>>>>On Tue, 2005-03-29 at 11:01 +0200, Matthieu Moy wrote:
>>
>>[...]
>>
>>
>>>>Of course.  However, I believe that full OS revision control is a
>>>>legitimate need that Arch could be ideally suited for.  
>>>>
>>>>I'm pretty sure all the changes I'd like can be handled with more
>>>>(optional) metadata.  I'm not against some scripting glue, but to
>>>>do this I still need to be able to store/retrieve some metadata
>>>>in the archive.
>>
>>Heh. The metadata discussion again :-)
>>
>>
>>>If you are asking for user-defined meta-data, how is this
>>>different from creating a user-defined text file listing the
>>>metadata that you are keeping track of [...]
>>
>>Well, it ain't different -- and it is. If Arch provides a
>>standardized repository for (generic) file metadata, it's gently
>>forcing applications to agree on one mechanism. 
> 
> 
> And there would be no need to externally care for move and
> remove of the metatdata along with a file (tla mv, tla rm),
> which is a PITA unless you store the metadata within the
> file.

With generic metadata there will always need to be some amount of
external care.

It seems like metadata could be conceptually broken up into two types.
There is 'first-order' metadata, such as file permissions, for which
arch is able to automatically apply the changes to archive files
transparently during a get or update.  Then there is 'second-order'
metadata, such as generic metadata, which currently doesn't exist.  With
this kind of metadata it would always be necessary for the user to
manually add the metadata for each file in the archive.  Arch could tell
you if metadata for a given file has changed, but it couldn't apply a
'patch' of any kind to alter your files based on that metadata.  That
would have to be done using hooks or some other method.

I don't believe there should be that many 'first-order' types of
metadata.  I would really like to push for having the (optional) ability
 to store 'first-order' uid/gid information, which arch would handle
transparently similar to how it does file permissions on *nix systems.
In addition, a facility to handle a single 'second-order' metadata
string would allow a user to attach their own metadata (in their own
format) to any file, then handle that however they want to in
commit/update/get hooks.

A single 'second-order' metadata string would basically give infinite
flexibility in terms of metadata.  That string could be anything:
CSV,XML,shell script,whatever.  It would be user-defined, and would
allow any number of creative facilities to be built on top of it.  All
arch would have to do is say 'your metadata string has changed for that
file', and hooks would take care of the rest.  Imposing a strict format
on generic metadata would be far too limiting.

-JE