Re: Small question on "CVS Diff"

Arthur Barrett wrote:
> We're talking at cross purposes - one of us is clearly not understanding
> the other.  It may seem absurd, but in my experience the best way to
> solve it is to keep explaining/clarifying/repeating until one or the
> other of us goes 'oh I get it'....

I know just how you feel... ;)

>> Just looking at the needs of a user of TCVS, if I have checked out a
>> project that is based on the "other" line endings from what
>> are in use
>> on my workstation, and chosen to keep the files in their
>> native format,
>
> Only CVSNT server (CVS 2.x) has any notion of 'keep the files in their
> native format'.

This (and your more detailed explanation below) is quite illuminating, 
not to say surprising.  Knowing intellectually that version control / 
content management systems are only required to reconstitute the bits 
they are charged with keeping - in whatever form they find convenient - 
is not the same as viscerally realizing that what is stored and how it 
is stored really has nothing to do with how the data I originate and 
retrieve is represented.

> ...
> I believe you are using sourceforge servers which are all 1.x based -
> they spoke to us briefly (years ago) about upgrading but nothing
> happened.  We encourage people who like TortoiseCVS/CVSNT etc to
> 'advocate' for the software our behalf, and writing to sourceforge would
> certainly be a way to do that.

The only CVS-based projects I deal with are indeed on Sourceforge.

>> then that means I accept the complications of using only local tools
>> that will work with and respect the files' format.
>>
>> If the "standard" behavior of pulling down a temp copy for the diff
>> operation does not follow whatever choice (WRT line endings)
>> I made when
>> I checked out the project, then that is "broken".
>
> Makes sense - except a couple of points:
> 1) if the option in TortoiseCVS says 'keep original line endings' then
> it is a textual error.  The option is --lf and means 'check out with lf
> line endings regardless of the original line endings'.
> ...

Again, not to get into implementation details, but... I understand the 
relationship of TCVS to a CVS client to the CVS server (at least well 
enough to make use of this assemblage of software).  But clearly my 
idealized view of textual data being stored in whatever "native" 
representation it started life as doesn't square with the reality of CVS 
servers - and I now get that they [in general] don't even keep meta data 
that says what that native form was.

>> Clearly, if there are implementation difficulties with making this
>> happen, then either we live with the unfortunate behavior, or
>> Torsten,
>> myself, or someone attempts to fix it... but surely the answer is not
>> that I have wrong or invalid expectations.
>
> Well put.  Except I feel that it is fixed - you are just using the old
> software which doesn't support it and there is no way to truly fix it
> without upgrading.

Not a practical option, as I don't control the servers.

> As I wrote to Torsten though - he can 'appear' to fix it by checking the
> line endings of each file rather than the CVS/Entries - but I've no idea
> how much effort that is (I suspect it's not simple or he would have done
> that in the first place).
>...
> I am extremely curious about one thing though: what are these files that
> you must use on windows and must be in lf line termination format?  What
> application creates these?  What tools are you using on windows that
> requires them in lf format?

One way of looking at it is that I have adopted conventions (or 
workflows) that give me the best chance of not inconveniencing project 
maintainers if I were to ship them some files I have been working on... 
I try not to hand over something that doesn't match whatever form they 
see as the "native" form of their data. ;)

So what happens in practice is that I get some idea of how the text 
lines *should* be terminated.  Sometimes it is enough to know that a 
project is developed primarily on Unix/Linux OR Windows.  Other times, I 
may have a snapshot of the source tree, and I can check that to 
determine this "native" representation.

In any case, once I know what that form is, I then make sure that all of 
my interactions with the repository respect that, which often at least 
influences (if not dictates) my choice of tools for working with that 
project.

If the world was different, and [e.g.] source files didn't start life as 
flat text files with some form of line termination, or at least ALL 
examination / interaction / communication of this data took place 
through the auspices of something like this line-termination-agnostic 
model of CVS's, then maybe the "agnostic" approach would be OK.

But that isn't how things actually are, and so I expect (apparently 
incorrectly WRT at least CVS) my storage system to have some sense of 
what my bits actually looked like when it first saw them, and to be able 
to reconstitute them exactly that way... sort of like MP3 vs FLAC when 
talking about sound recordings - FLAC can recreate the exact wave data 
that was on the digital medium.

Thanks for clearing up a certain amount of confusion.

Robert Roessler

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev