[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: tomas
Subject: Re: [Gnu-arch-users] Re: arch with 'special files'
Date: Tue, 5 Apr 2005 11:03:28 +0200
User-agent: Mutt/1.5.3i

On Tue, Apr 05, 2005 at 09:07:12AM +0200, Jan Hudec wrote:
> On Mon, Apr 04, 2005 at 02:03:56 +0200, Robert Widhopf-Fenk wrote:
> > On Friday, April 1, 2005 at 02:38:56, Josh England wrote:
> > > It seems like metadata could be conceptually broken up into two
> > > types. There is 'first-order' metadata [...]


> Well, there is still a bit special case of "meta-data used by
> diff/patch". And which ones that are has to be hard-coded.
> There would be a diff algorithm, and a list of filters to apply.
> However, there is a problem if the filter is not fully reversible [...]

Yup. This metadata business doesn't solve everything. Especially with
diff/patch you get no end of possibilities ;-)

A while ago, e.g. the idea was pushed around to have file-type specific
diff/patch. Of course, this file type would most appropriately be expressed
via metadata... or not?

Inexact patching for jpeg images anyone? Or for (ugh!) XML RSS files[1]? Or...

> We could minimalize this problem by implementing these filters line-wise
> in diffutils. Sounds complicated enough?

It does indeed.


> > The svn-book has a section on "Why properties?" and IMHO it
> > makes some sense ...
> That section does in fact advocate the Reiser's files-as-directories.
> But in the working copy, the properties are stored separately anyway...
> The think they advocate in the begining of that chapter is really an
> argument for the Reiser's files-as-directories, but subversion does not
> (and cannot) do that for the client (The server does it).
> And it has to be said, that even the files-as-directories don't really
> solve much, because they need all the applications that manipulate them
> be aware of the extra semantics (ie. you can't copy them as normal
> files...)

*This* is one of the things we could solve quite elegantly with file
ids. As the files get moved around, Arch can keep track of them quite
nicely and keep the link to the (not natively managed) attributes.

For each OS[2] there be a set of hook scripts to do the mapping magic
on check-out and check-in (those not necessarily being considered part
of Arch -- or better: Arch determines which metadata it explicitly
cares for).

OTOH i understand quite well the guru's reluctance to even think about
that :-)

[1] Yeah. XML is technically text. But just technically. Line structure
    is an accident, more or less and is only useful in hand-generated XML.

[2] I take OS here to mean `the environment where the project tree resides´´.


-- tomás

Attachment: pgpTY5lIFRuOu.pgp
Description: PGP signature

reply via email to

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