RE: line endings in text files and -kb

[Arthur Barrett]

Ittay,

> ahh, the old trick to tell people to shut up.

Since I havn't said that then you should assume instead that what I'm
saying is what I've said.

> 1. i did not ask for anything. i was asking 
> how cvs behaves when -kb is used. 

And it's been explained in the first reply - the fact that the thread is
still going indicates that there is more too it.

> 2. i fix it and then you are in charge to 
> put it in the next release and propagate 
> it to the next update of redhat? or 
> should i wait a few months till that happens? 

No. It's all much more complex than that.

However if you've fixed it, then you've tested it and installed it
already - no waiting for anyone else.

Remember the 'free' in 'free software' is not about the price - it's
about the 'freedom' to customise the code (eg: to perform better for
your use).

> 3. i think such a thing is already 
> implemented in cvsnt, why not run a diff 
> between cvsnt and cvs and get a nice patch? 

Well based on the information you provided - you are already using CVSNT
client so there is no need to, I believe that TortoiseCVS even provides
a nice GUI way of handling the 'checkout with unix line endings'.

If you want to run CVSNT server - go ahead and install the RPM.

If you want the answer to "Why not merge CVS and CVSNT" and other
frequently asked questions, then read the FAQ:
http://www.march-hare.com/cvspro/faq/faq1.asp#1da


> 4. telling someone to go into a source 
> code of some tool that has been in existence 
> forever and expect him to do so is naive at 
> best. 

The only reason why there are ever any changes to any 'free' software is
that someone volunteers to do it.  They are no different from you or I.
There are also CVS and CVSNT development newsgroups to assist people in
the contribution process and answer technical questions about the code.
CVS has been around for 22 years or so and it would not have lasted that
length of time if it was not easily maintainable and accessible for new
programmers to contribute.

Regards,


Arthur Barrett