[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Maintaining branches...
From: |
Eric Siegerman |
Subject: |
Re: Maintaining branches... |
Date: |
Thu, 14 Jun 2001 14:04:08 -0400 |
User-agent: |
Mutt/1.2.5i |
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)
- Re: Maintaining branches..., (continued)
- Re: Maintaining branches..., Brett Neumeier, 2001/06/12
- RE: Maintaining branches..., Stephen Cameron, 2001/06/12
- Re: Maintaining branches..., Ralph Mack, 2001/06/13
- Re: Maintaining branches..., Mike Castle, 2001/06/13
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Eric Siegerman, 2001/06/14
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Greg A. Woods, 2001/06/14
- Re: Maintaining branches...,
Eric Siegerman <=
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Re: Maintaining branches..., Derek R. Price, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Re: Maintaining branches..., Derek R. Price, 2001/06/14
- Re: Maintaining branches..., Mike Castle, 2001/06/14
- Off list comment (was: Re: Maintaining branches...), Mike Castle, 2001/06/18
- Re: Maintaining branches..., Paul Sander, 2001/06/14
- Re: Maintaining branches..., Eric Siegerman, 2001/06/14
- Re: Maintaining branches..., Paul Sander, 2001/06/15