Re: Small question on "CVS Diff"

Hi Robert,

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'....

> 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'.

You can find the version number of the server you are using by typing
'cvs ver' in a sandbox.

CVS 1.x understands two types of files:
1) text.
No record is ever kept of the original line endings, it is stored in an
internal format in CVS/CVSNT Server with each line delimited.  Each CVS
client will re-create the file in the format for the native system:
os/400 as fixed length records, DOS/Windows has cr+lf, Mac has cr, linux
has lf.  Nowhere is it ever stored what the 'original' line endings were
or what the 'preferred' line endings are- a 'text' file is a file with
NO DEFINED line endings (in CVS 1.x)

2) binary.
The file is stored in CVS/CVSNT server exactly as it was on the ORIGINAL
client.  Since there is no concept of the end of a line then no line
based options are available, including merging.  Contrary to popular
myth - the revisions are still stored as 'deltas' (diffs).

When developing CVSNT we realised that these limitations are counter
productive to certain workflows and we added the ability for the
'preferred' line ending of a text file to be stored (either at initial
'add', 'import' or later on in time at a specific revision).  In total
CVSNT 2.x supports an awful lot more workflows than CVS 1.x because of
this and hundreds of other changes.  Bot without that 'meta data' there
is no way to support those features - ie: if you use CVS Server 1.x you
get CVS 1.x features, if you use CVSNT Server 2.x you get 1.x features
and ditto for 3.x.


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.


> 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'.

2) TortoiseCVS is a GUI not a version control tool - neither TortoiseCVS
nor CVSNT stores your 'checkout options' anywhere, so it cannot
reference them later.  This is a problem we fixed in CVSNT 2.x, because
you don't need to use an undocumented option like --lf, - but it
requires CVSNT 2.x server to make it work.  That's not technically
changeable - CVS 1.x server just doesn't have the functions required to
store this stuff.  It's taken me 5 years to work this out - I understand
that it makes no sense but believe me it's true - the server is
responsible for creating the files on the client, not the client - this
is the opposite of SVN (the SVN team deliberately changed it and
discovered all the problems that causes) which has the client do
everything and the server very little.


> 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.

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).

The bottom line problem is that you are relying on undocumented
behaviour of a function that wasn't designed for the purpose to which
you are using it and a function/option that has already been removed
once (due to serious repository corruption issues) and is very very
likely to disappear again.  You can still do your workflow - but you
need to use a different option and use a newer version of the (server)
software.

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?

Regards,


Arthur Barrett

------------------------------------------------------------------------------
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