Re: metastore (was: Track /etc directory using Git)

[Daniel Barkalow <barkalow@iabervon.org>]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1796 bytes --]

On Tue, 2 Oct 2007, David Härdeman wrote:

> On Tue, Oct 02, 2007 at 08:53:01PM +0100, martin f krafft wrote:
> >also sprach David Härdeman <david@hardeman.nu> [2007.09.19.2016 +0100]:
> > > But I agree, if any changes were made to git, I'd advocate adding
> > > arbitrary attributes to files (much like xattrs) in name=value
> > > pairs, then any extended metadata could be stored in those
> > > attributes and external scripts/tools could use them in some way
> > > that makes sense...and also make sure to only update them when it
> > > makes sense.
> >
> >So where would those metdata be stored in your opinion?
> 
> I'm not sufficiently versed in the internals of git to have an informed
> opinion :)

My theory was that we would provide an API for getting the "current state" 
listing with all of the filenames and matching contents, and leave it up 
to metastore to put things in the filesystem; in the other direction, 
metastore would build up this state, and we'd store it.

People who are using this in practice would set a config option to 
delegate the "working tree" filesystem I/O to metastore, while other 
people could interact with the state as files describing the state, and 
could therefore specify operations that are impossible or prohibited on 
the filesystems that their development is done on.

(This would effectively be like giving people a convenient way of setting 
attributes on entries in a tar file, such that they can edit it to 
represent a stste that they can't necessarily create in their own 
filesystems, and version controlling that; but more convenient, since the 
file contents are represented as file contents and the attributes are 
plain text in a listing of some sort)

	-Daniel
*This .sig left intentionally blank*