"Derek R. Price" <[EMAIL PROTECTED]> writes:
> It does have an obvious rebuttal: As I understand it the only text
> file conventions we are worried about are the three different EOLs.
There may be others, but I'm sure those 3 cover >99% of CVS users.
> What is stopping us from writing the db files natively from whatever
> platform but allowing any of the three line endings when reading
> them in?
(By "db files" you mean CVS/Entries, CVS/Root, and CVS/Repository,
right?)
I agree. This makes sense to me, and would make my life *much* easier.
IF AND ONLY IF CVS also simultaneously gained the extra intelligence
to determine the original (checkout time) line-ending convention of
each *workfile*, and preserve that through subsequent operations.
> Of course I think the answer may be that this solves some problems
> while encouraging others - namely that it may created a false belief
> that using a workspace shared across NFS is now safe or that FTP'ing
> your workspace between Windows & UNIX is safe.
It's already "possible", even "easy", to do *lots* of things in CVS
that could lead to disaster if used improperly. This is no
different. In the end I'm fairly certain it would *eliminate* more
frustration than it caused.
> Of course, applying this modification to .cvspass might be
> reasonable. Then a user could use the same $HOME under UNIX & DOS
> usefully...
And also .cvsrc. Yes, although I don't use the same home directory for
Windows and Unix, I think that should be done even if support isn't
added for differing line-endings in db and/or work files.
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
