[Top][All Lists]

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

Re: [Gnu-arch-users] Encoding handling proposal

From: Michael Poole
Subject: Re: [Gnu-arch-users] Encoding handling proposal
Date: 05 Sep 2004 18:42:44 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3

Marcus Sundman writes:

> Here is my proposal of how *I* think a CM system should handle the "encoding 
> issue" and some related issues. You may have a different opinion, and if 
> you do it'd be nice to hear it, but no trolling, please.
> (See the "Notes" section below for comments regarding each point.)
> A) There should be support for both mandatory and optional metadata 
> attributes associated with each file in the repository.
> B) "Content-Type" should be a mandatory metadata string attribute.
> C) "Auto-Filter" should be a mandatory metadata boolean attribute.
> D) There should be a filter/plugin architecture to enable a transcoding of 
> files on input and output based on their content-types and user settings 
> and user-provided parameters.
> E) Utilities such as "diff", "merge" and "annotate" (aka "blame") should be 
> provided by plugins mapped to content-types.

Except for the Auto-Filter idea, similar issues have come up in the
past in the context of arch's inventory of files.  I think that is the
natural place for arch to know about file formats -- whether the
inventory uses MIME content-types or something else.

I share Stefan's concerns about non-transcodable code points.
However, if arch's format handling is done properly, it can let each
of us implement archives that work the way we believe they should, and
let us work on each other's archives without problems.  That ability
is more important than one of us convincing the other of The One True
Approach To Transcoding.

> F) Commit comments and other string attributes should use UTF-8.
> G) Filenames and paths should use UTF-8 in the repository, and be transcoded 
> to the proper encoding when a client accesses the local file system.

This makes sense; since commit comments are stored in well-known files
inside the working tree, they would go through any transcoding that is
applied to text files.

Perhaps once xl is implemented, it would be an appropriate platform
for format-specific diff/patch utilities.


reply via email to

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