info-cvs
[Top][All Lists]
Advanced

[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>






reply via email to

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