gnu-arch-users
[Top][All Lists]
Advanced

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

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


From: Jan Hudec
Subject: Re: [Gnu-arch-users] Re: arch with 'special files'
Date: Tue, 5 Apr 2005 09:07:12 +0200
User-agent: Mutt/1.5.8i

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, such as file permissions,
> > for which arch is able to automatically apply the changes to archive
> > files transparently during a get or update.  
> 
> There should be only one way to access and modify.

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, as
would be the case with eg. charset conversion. The problem here is, that
if we localize the file and then canonicalize it back for taking
a difference, it will differ. And if we localize the pristine copy and
canonicalize the difference, it may not apply (because the context was
corrupted).

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

> > A single 'second-order' metadata string would basically give
> > infinite flexibility in terms of metadata.  
> 
> Why just a single one, because its easier to implement?
> 
> Well I might have been poisoned by subversion.  Actually, in
> svn I do force some file to have the "correct" line ending
> by svn:eol-style and for tla I would like to mark some files
> where my tla-export performs keyword expansion.
> 
> 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...)

-------------------------------------------------------------------------------
                                                 Jan 'Bulb' Hudec 
<address@hidden>

Attachment: signature.asc
Description: Digital signature


reply via email to

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