RE: code submission

[Samson Chan]

>This seems like the wrong way to go about this.

>First of all, old CVS clients will _not_ choke on an Entries file with 
>extra data on a line after the last /, but they _will_ delete the extra

>info if they rewrite the entry record.

Actually, the info is written as the first character in the line.  So it
will say
    U/file1/.../
    /file2/.../
    D/dir1/
    C/file3/.../
CVS currently skips the lines it doesn't recognize. 

>Second of all, shouldn't the GUI just be parsing the CVS output?
Status 
>change frequently anyhow, so what's the difference if the GUI has to 
>notice a timestamp change, then run cvs update, then parse the 
>Entries.GUI file or if it has to notice the timestamp change, then run 
>cvs update, then parse the CVS output?

The GUI doesn't constantly check for timestamp changes; that'll be too
much processing.  The idea is to store the query update/status results.
It's very inefficient to continuously parse the CVS output.  If the GUI
client does the query status storing, it will have to parse the output,
and store it.  So why not just store it right when the query status
takes place?  All the client has to do is read the Entries file and
display the status.  I don't know how other GUI clients work, but WinCvs
regularly scans the Entries files to update the status of files
graphically (such as modified, removed, etc.)  These kinds of changes
are recorded in the Entries and Entries.log files.  Why shouldn't CVS
store query status too?  

  - Samson