Re: Spaces added ... and line endings in general

[Laine Stump]

address@hidden 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".