Re: [PATCH] cvsserver: Make always-binary mode a config file option

[Andy Parkins <andyparkins@gmail.com>]

On Wednesday 2007 February 28 11:36, Martin Langhoff wrote:

> I am a bit confused here... why would we want to do this? We don't
> want to support keyword expansion, and that happens at the server end

Well, at the moment you don't, but that might happen in the future with 
certain settings in .gitattributes.  It might be nice to have a switch to 
disable that available.  However, that's not why I added this.

> anyway. CVS clients are pretty dumb and will just write out the file
> we give them. When we are going to diff, they send the file to the
> server, and the server runs the diff. Etc. No smarts at the client end
> that care about -k options.

I think your supposition that no client cares about the -k options is wrong. 
CVS clients don't just write the file untouched.  CVS stores all text files 
with UNIX line endings, the client then uses the text/binary flag to decide 
if line-ending conversion should happen.  Checking out to unix would of 
course not require any conversion so the file would be untouched.  Not so for 
Windows clients.  That was what prompted me to make this patch.  I keep some 
binary images in the git repository, when they were checked out with 
TortoiseCVS they were having all the 0x0a (LF) bytes changed to CR LF, and 
thus mangling the images.  

> Or are you trying to control newline mangling on Windows/Mac clients?
> I'm not even sure where that mangling happens. If that's the case, a

It seems to be happening in the client.  In fact it's a given that it happens 
in the client as only the client knows what the local line ending rules are.

> repo-wide toggle is useless, you really want the per-file-type rules
> you mention.

"Useless" is a strong word; especially as I'm finding it very useful :-). 

Yes, a per-file option would be better - but git has no support for that at 
present, so I need a work around.  Most windows editors will cope fine with 
UNIX line endings, so not converting them doesn't cause a problem.  On the 
other hand, mangling every binary file /does/ matter.  So, for me, the better 
default is to not mangle anything (i.e. tell CVS that everything is binary 
and should be preserved as is).


Andy
-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com