Re: Maintaining branches...

[Eric Siegerman]

On Thu, Jun 14, 2001 at 12:57:30PM -0400, Greg A. Woods wrote:
> [ On Wednesday, June 13, 2001 at 23:12:16 (-0700), Paul Sander wrote: ]
> > Subject: Re: Maintaining branches...
> >
> > Is there some reason why the -j's could not be recorded in the CVS 
> > directory,
> > [...]  At commit time, the notations could be recorded in the RCS
> > files for future use.
> 
> That's the trick.  [...] Is doing it as part of the commit message sufficient?

NO!  One wants to be able to query based on this; more
importantly, CVS itself needs to be able to do so to implement
merge-tracking.

> How do you do that without impacting RCS compatability???

The RCS file format is extensible; this shouldn't be a problem.
I posted some time ago on this subject.  I was going to say
"check the archives", but then did so myself and discovered that
the info-cvs archive at egroups stops in Dec.  2000.  So here's a
repost of my original message.  Is there another archive, so I
won't have to do this in future?

(Greg, this was written in the context of binary-file support.
Please try to ignore that, and just use it as background :-)

On Thu, 4 Jan 2001 12:54:12 -0500, I wrote:
> Subject: Re: Proposal to fix CVS binary file implementation
> 
> 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
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)