[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: CVS and unicode
From: |
Derek Price |
Subject: |
Re: CVS and unicode |
Date: |
Mon, 12 Sep 2005 10:49:24 -0400 |
User-agent: |
Mozilla Thunderbird 1.0.6 (Windows/20050716) |
Larry Jones wrote:
>Pierre Asselin writes:
>
>
>>It would be nice if CVS decoupled keyword expansion, text/binary,
>>mergeability and line-ending conversion independently of one another.
>>
>>
>
>Yes, it would.
>
>
>
>>Right now they are all conflated in the RCS "expand" string and
>>only a few combinations are supported. The RCS file syntax allows
>>arbitrary strings there so it would be possible to extend the
>>behavior but that might break compatibility with the RCS utilities
>>(which I regard as a bad idea).
>>
>>
>
>Aye, there's the rub. If anyone has any good ideas (and, preferably,
>code) to do the former without the latter, please share!
>
>
Well, how does RCS react to an unrecognized keyword string? With a
warning, an error, or silence, and what sort of substitution occurs?
Regardless, the new modes could be stored in a newphrases (see
rcsfile(5) <http://ximbiot.com/cvs/wiki/index.php?title=Rcsfile%285%29>)
in one of two locations.
The first would be a newphrase in the header block, and when it existed
could be used in preference to the "expand" string ("expand" would need
to be marked binary for all modes without equivalent in RCS). Mostly
this would behave like keyword mode used to, and with careful choice of
flag characters, could probably still be administrated with `cvs admin -k'.
The second would be a newphrase attached to revisions. This would be
really cool, because keyword mode could thereafter be versioned (if,
when walking the diff tree to the requested revision, a new expansion
mode is found, it should be inherited - this would avoid the need to
convert old repositories by attaching modes to all past revisions). The
old RCS "expand" would need to be "b" once an RCS-incompatible mode was
assigned to any revision, as with the former suggestion. Also, a new
administrative interface would be needed to set these modes per revision
and probably new keyword modes would need to be committed, as with
changes to the file. This would, unfortunately, be a lot more work.
Sorry, no patches here.
Derek
--
Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125
<mailto:address@hidden>
- Re: CVS and unicode, (continued)
- Re: CVS and unicode, Spiro Trikaliotis, 2005/09/11
- Re: CVS and unicode, Christian Hujer, 2005/09/11
- Re: CVS and unicode, Jim Hyslop, 2005/09/12
- Re: CVS and unicode, Christian Hujer, 2005/09/12
- Re: CVS and unicode, Jim Hyslop, 2005/09/12
- Message not available
- Re: CVS and unicode, Pierre Asselin, 2005/09/11
- Re: CVS and unicode, Larry Jones, 2005/09/12
- Re: CVS and unicode,
Derek Price <=
- Re: CVS and unicode, Christian Hujer, 2005/09/12
RE: CVS and unicode, Arthur Barrett, 2005/09/05
RE: CVS and unicode, Arthur Barrett, 2005/09/06
RE: CVS and unicode, Arthur Barrett, 2005/09/07
Re: CVS and unicode, ai26, 2005/09/10