bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: code submission


From: Samson Chan
Subject: RE: code submission
Date: Fri, 7 Mar 2003 13:52:31 -0600

>True, but did you want CVS to skip the line or cache the data with the 
>rest of the file data?  The Entries file format was designed to be 
>expandable by adding data after the last "/".  I would think it would
be 
>more efficient not to repeat some data like file name unless you wanted

>to be able to interoperate with older clients that might otherwise 
>delete the data.

I want to read the line and cache it.  I don't need it to be backward
compatible, but I made it so it can be.  


>At least under Windoze, it is possible to register for directory and 
>file events so that the OS will automatically send your application
call 
>back notifications when files are modified.

True, but I don't need to constantly monitor the status of files needed
updating.

>>  The idea is to store the query update/status results.
>>It's very inefficient to continuously parse the CVS output.
>>
>
>Not any more inefficient that running CVS anyhow and then parsing the 
>contents of the Entries file.

But CVS has to be run either way to determine if a file has any
conflict, or needs update, etc, and the Entries are parsed to get the
"latest" file info.  So it saves the extra step of parsing the output.

>It the difference between information that CVS actually needs to know 
>about the status of a file and cached data that may become out of date 
>between runs of CVS.

It's true that cache data may be out of sync, so this extra info stored
is an indication of this out of date issue.  Put it this way, the
Entries stores various info relating a file: name, version, timestamp,
etc.  But it has no info of a file's status compared to the repository.
I see this status should be a part of a file's information in the
entries.  It represents the status of a file run by the last query
update.  So users can see that based on their last query update, what
they should do with the file.  It might not be accurate, but they can
query again to get the latest status.
This info is not stored for a command line CVS, because users have to
rerun the query status every time to see what's been changed.  But for a
GUI client, it visually lists all the files and its property.  So the
file status needs to be stored somewhere, and the entries file seems
like a good choice.

  - Samson




reply via email to

[Prev in Thread] Current Thread [Next in Thread]