Re: CRLFs and Update/Checkout

Jeff Cantin wrote:
> Hey all. 
> 
> My group has been using the Javacvs library for a while with some
> internal config mgmt tools, and it's been working well. It has a nice
> API, broad featureset and even seems to work well with multiple
> threads. One problem has been lingering, though, and no rearranging
> of commands or local settings has been able to fix it. I'll try to
> relay the problem with a situation: 
> 
> 1. Checkout a module on your computer into directory A. 
> 2. Have someone else checkout, modify, and commit the module on
> another computer. 
> 3. Run an update on your computer in directory A. 
> 
> 4. Checkout the same module into directory B (after the changes are
> made). 
> 5. Compare the files in the two directories. 
> 
> The problem is that remote modifications are not always picked up by
> an update - a persistent issue for us. Running another checkout into
> the same directory (which is similar to update anyway) results in the
> same problem. Setting the checkout to read-only and read-write
> doesn't affect it. The only way to get the right versions when there
> are problems is to wipe the directory and re-checkout. 
> 
> The update appears to 'fail' because it thinks the local files are
> modified. Sometimes this results in a conflict, but usually it
> appears that the files just don't change. Knowing java and CVS, the
> real issue could be in several places, but this is only showing up
> for us on Win32 boxes, implying some file-format or CRLF problem (go
> Bill). I've also heard from an Ant developer that one of the reasons
> they're using command-line cvs for their CVS task was licensing and
> CRLF issues in the Java cvs APIs. 


yup. The CRLF conversions are a pain. if you want to dig into the code, check the cvsclient.file 
package..

the algorithm for sending files to server during update is following:
1. check the timestamp on the file with the timestamp in the Entries file
if they match, send the Unchanged request to server (the file itself is not sent at all and only 
remote changes are taken into consideration based on the timestamp matchon the client and server)
if they don't match, the file is considered lically modified and the content is sent to server to 
resolve possible conflicts (that's when the CRLF stuff could matter.)

<rant>
A general porblem with java is the old java.io package that doesn't effectively allow mixing 
text-based protocol(processed per line) and binary-based data in one stream.. I believe the javacvs 
library would be best rewritten using the javax.nio packages coming with JDK 1.4 that should fix the 
inherent problems.
it's also partly problem of cvs which is not client-server by default but rather by coincidence and 
some hacking. For a VCS system that's close to cvs (possible replacement) without the cvs problems 
see: http://subversion.tigris.org/ .. I've discovered the project just lately..
</rant>


> 
> I tried to spend a few hours last week digging into the lib code, but
> all I could come up with is speculation. It looks like text files are
> pulled from CVS and written locally with the OS-default line ending,
> so they should be written correctly to disk. Perhaps the problem is
> in the diff stage where the line is compared against CVS, and where
> there could be an extra char at the end of the line. I'm going to try
> to spend some more time this week poking around; anyone else's
> feedback would be a great help. 
> 

(again the cvsclient.file package is the place to look at) when sending files back to server, we 
convert back to unix style endings equired by the server.


Hope that helps.

Milos Kleint

> thanks
> Jeff
>