[Top][All Lists]

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

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

From: Charles Duffy
Subject: Re: [Gnu-arch-users] Encoding handling proposal
Date: Sun, 29 Aug 2004 18:09:13 -0400
User-agent: Internet Messaging Program (IMP) 4.0-cvs

Quoting Marcus Sundman <address@hidden>:
> Sorry, my fault, I wasn't clear enough.
> Diff tools are used for two things: A) for generating patches, and
> B) for displaying the difference between two objects to the user. In
> my proposal this would be split up so that functionality A is the
> same for all files but functionality B is pluggable. (The same goes
> for merge tools.)

Hmm -- being able to view the difference between two files in a way
sensitive to their type without being able to apply those changes in a
way sensitive to the file type seems like rather a waste. For
instance, my company has been in a situation where it would be
valuable to have a revision control system that could intelligently
merge files in a specific XML-derived format (specific to that format
so we could have logic to do the merge nicely and guarantee that the
resulting document still complies with its DTD). We could use that. We
could also use a generic per-tag metadata-storage mechanism
(particularly if that metadata could be used to determine stuff like
which diff/patch tools to use, say via some furth-based goo). I don't
something as specific as encoding-only tracking would be useful to us,
but hopefully the generic metadata-storage system that would help us
would also be useful to *you*.

Mostly, what you're talking about strikes me as a problem that most of
the places I've worked at would solve through policy -- something
along the lines of "files (of this type/in this directory) will have
*this* encoding and _only_ that encoding, and coders who break that
policy shall not get a cookie". Could it be useful to many sites (such
as your own) to have a tool that enforces this policy? Sure! But then,
I think that such a tool could be built without making it a mandatory
part of Arch.

My gut preference is for use of extended attributes (where supported
and preferred) or Arch-managed, user-defined, strictly optional,
tag-specific key/value pairs (where not). Making specific pairs --
such as encoding type -- mandatory could be done as a site-specific
policy enforced by a PQM; there's no need to make it mandatory for
sites that don't care. Ideally, furth code could be written to make
use of this metadata for things like deciding how to display and/or
perform diffs, and so forth.

Of course, I'm just sitting up here in the peanut gallery -- it's not
me that needs convincing.

reply via email to

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