info-cvs
[Top][All Lists]
Advanced

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

Re: Proposal to fix CVS binary file implementation


From: Eric Siegerman
Subject: Re: Proposal to fix CVS binary file implementation
Date: Thu, 4 Jan 2001 12:54:12 -0500
User-agent: Mutt/1.2.5i

On Thu, Dec 28, 2000 at 03:22:36PM -0600, David H. Thornley wrote:
> It could be worthwhile expanding the RCS
> format to do some better handling of binary files.  It would be
> possible to improve the handling of binary files while keeping
> most of the code base.

The extension to the RCS format (ie. the data-storage layer)
should be a general one.  It should provide for storing an
arbitrary set of named attributes (ie. key/value pairs) per
revision.  There should also be a global set, whose attributes
apply to all revisions (as the keyword-expansion setting
currently does).

Then the upper layers (ie. CVS proper) can define attributes to
suit its purposes, eg:
  - binary/text flag
  - MIME type
  - keyword-expansion preferences

(Whether these specific attributes should be per-revision or
global is open to debate -- indeed, the debate is currently
happening -- but in either case, under my proposal the decision
does not affect the RCS layer.)

More things that fall out of this:
  - One can imagine adding a per-revision attribute that says
    where in the sandbox this ,v file lives.  Poof -- the
    revision-controlled mapping that Paul Sander (I think) was
    talking about.  (There'd still be a need to map the other
    way, from sandbox name to ,v file -- but maybe the
    CVS/Entries file could do that).

  - One could add attributes for things like file permissions and
    the like -- anything that should be revision-controlled, but
    currently isn't.

  - Another attribute could be the filesystem object type (so
    named because "file type" is ambiguous; it can also refer to
    MIME type).  More attributes to contain symlink values,
    device numbers, etc.

  - Expansion of arbitrary keywords (subject to keyword-expansion
    settings of course): if there's a "Foo" attribute, and the
    file contains a "$Foo$" keyword, expand it.  (Needs an
    interface for setting them; to prevent people from using this
    to break CVS's own attributes, perhaps prepend "USER_" to all
    attributes set via the UI.)

Any number of worthwhile proposals have foundered on the
RCS-compatibility problem.  So if it has to break, break it
*once* -- in a general-enough way that the RCS layer need never
change again.


Looking at rcsfile(5), I find that provision has already been
made for adding new metadata, both per-revision and globally --
the "newphrase" construction in the grammar.  So perhaps the
format doesn't have to break after all; what I'm suggesting is
already basically there.  Rather than adding an attribute
mechanism, CVS could just define "newphrase"s where necessary,
since, as David Thornley points out, CVS has internalized its RCS
access, and is thus no longer dependent on the RCS code itself.
(I just checked; RCS 5.7 can handle files with custom metadata,
but it prints a warning.  So even if CVS does extend the format
in this way, that won't prevent people from using RCS to get at
the data in an emergency.)

If CVS opts for adding "newphrase"s, enhancing binary-file
handling is a matter of defining one or more of them to contain
the necessary metadata, and having CVS *ignore* the current
keyword-expansion flag for any ,v file which contains the
new-style metadata (for compatibility, the old flag should be
honoured for files without new-style metadata).

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
Interviewer: You've been looking at the stars all your life:
Is there anything in astrology?
Arthur C. Clarke: It's utter nonsense.  But I'm a Sagittarius,
so I'm naturally skeptical.



reply via email to

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