Colin Putney wrote:
> 
> On Friday, May 2, 2003, at 03:57  PM, Tim Rowledge wrote:
> 
>>> Traditionally Smalltalk has used CR linends, so DVS probably ought to 
>>> use that; however it really shouldn't matter so long as it is 
>>> properly consistent.
> 
> 
> The reason DVS messes with line endings is that it's meant to be used 
> with CVS, which doesn't diff and merge properly with non-LF line endings.

I don't think this is actually quite true, is it?  I was always led to 
believe that if you check in a text file with the correct line-endings 
used on your system the cvs client will convert it to LF before storing 
it in the repository.  When somebody checks it out, they will get it in 
*their* native line endings.  The problem is that if you check in a file 
in the wrong line endings for your system, they don't get converted.

This is problematic if you copy the file to another system or work (as I 
do at home) on one system while committing from another (I work on a 
mounted filesystem - it's easier to work on a samba share than get cvs 
working with ssh on windows).

Of course the solution of always filing out CR/LF doesn't quite work 
either because if a windows user does the checkin it should get 
converted, but other users won't convert it.  Basically, this is jsut 
another argument for getting Monticello to a fully working version 
control system that doesn't depend on CVS.

But...

Just yesterday, I tracked down a problem with line endings in Monticello 
which may be the same problem DVS has.  File In will accept any line 
endings because it uses a CrLfFileStream, but when you do a Load, it 
displays a file list.  The file list, unfortunately returns a 
StandardFileStream by default so you get LFs embedded in your method 
source.  The easy workaround is to either File In immediately after 
loading, or better yet, change your default file stream to 
CrLfFileStream by changing the #concreteStream method (anyone know if 
there are negative consequences to this?).

I wonder though, is there a reason why we don't have a File class? 
Haven't thought too much about how it would work, but presumably it 
could hold onto a directory and a filename and could then provide the 
directory, or provide a stream, allow you to delete the file, change its 
permissions, etc...

Julian


-- 
julian at beta4.com
Beta4 Productions (http://www.beta4.com)