[EMAIL PROTECTED] writes:
> LS> I agree. This makes sense to me, and would make my life *much* easier.
> LS> IF AND ONLY IF CVS also simultaneously gained the extra intelligence
> LS> to determine the original (checkout time) line-ending convention of
> LS> each *workfile*, and preserve that through subsequent operations.
>
>
> You can (kind-of) do that today with the -kb option (set via WRAPPERS)
But that has other unwanted side effects (doesn't it disable keyword
substitution?), and only has the effect of removing *all* line-end
conversion.
> However what would be REALLY useful would be:
>
> Can set MODE of a file to (say) DOS, UNIX, MAC ... others
>
> (personally I don't need this as all the tools I use accept all conventions
> :-)
Mine too *kind of*. Unfortunately, I occasionally make the mistake of
adding a line using MS Visual Studio (only during debugging when I
forget to switch to Emacs!), and it puts a CRLF-terminated line in the
middle of an all-newline file. Bah! Other than that, the only tool I
use that doesn't accept/deal with multiple line-end conventions is _CVS
itself_.
> But it would need to be set in variety of ways:
>
> setting on file,
> overridden by .rc file,
> overridden by environment,
> overridden by cmd options
YES!!!! This is exactly what I'd like to see! (naysayers be damned! ;-)
> Why all this complexity? Consider:
>
> I'm on DOS but I want to edit a shell script run on the PSERVER on Unix
>
> I'm a web server/cron-job and I'm doing this checkout on the Unix box,
> so that
> an overnight build running on a MS-DOS pc can make the binaries U-2-D.
>
> I'm using a MAC to checkout files to add some comments for my group
> who use MS-DOS pc to develop code :-)
Well, most of those cases already "just work". The only problem is
when you do the checkout on platform X, then work with that work
directory on platform Y. I actually end up doing that a lot, often
unintentionally, because I develop code that runs on both Windows and
Unix, and happen to prefer doing everything except compilation on
Unix.
> Strikes me this might actualy make the CVS code simpler :-) ... instead
> of converting to local conventions (thus needing too know what they
> are) you would simply pass the cannonical file through a filter which
> 'localised' it as requested.
Right now CVS is relying on the C library file functions (fopen,
fputs, etc) to do the "filtering".
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
