Paul Sander wrote:
> I agree in principle with your statements and your proposal, but I observe
> two omissions:
>
> 1. There is a class of text file that is not mergeable, but requires newline
> conversion. CVS does not currently support that class of file, but I
> believe it should. Supporting that class of file would mean adding up to
> four more keyword expansion modes, and modify CVS to apply the proper merge
> semantics. Examples of such files include Frame Maker MIF documents and
> uuencoded files. It could be argued that Rich Text and HTML fall into this
> category also.
Why isn't the -mCOPY mode sufficient to handle these cases?
> --- Forwarded mail from [EMAIL PROTECTED]
>
> Here's what I would propose (and I underscore *propose*):
> 1) Maintain the current keyword expansion modes, as persisted in the =
> archive or in the local working area in the Entries file as "kv, kvl, k, =
> o, b, or v";
> AND
> 2) EITHER:
> a) Provide a new command line keyword expansion option "-km" on cvs =
> update and cvs checkout to support merging. The effect would be that =
> the working area local keyword substitution mode would overridden to "k" =
> for all but binary files, which would remain "b".
> OR
> b) Change the current behavior of update and checkout to never =
> override the archive-stored default keyword substitution mode for binary =
> files.
Or create an extra expansion mode which isn't overridden by options passed to
update or checkout but can still be changed using cvs admin. Then there aren't
any modes it doesn't make sense to attach permanently to a file. Not sure what
issues that raises with backwards compatibility with RCS, though...
Derek
--
Derek Price CVS Solutions Architect ( http://CVSHome.org )
mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com )
--
I cannot live without books.
- Thomas Jefferson
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
