bug-cvs
[Top][All Lists]
Advanced

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

Re: code submission


From: Derek Robert Price
Subject: Re: code submission
Date: Fri, 07 Mar 2003 11:21:21 -0500
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02

Samson Chan wrote:

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.


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.

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.


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.

 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.

 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?

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.

Derek

--
               *8^)

Email: derek@ximbiot.com

Get CVS support at <http://ximbiot.com>!
--
The Indian chief said he did not go to war for every petty injury by itself,
but put it into his pouch, and when that was full, he then made war.  Thank
Heaven, we have provided a more peaceable and rational mode of redress.

                        - Thomas Jefferson to William Johnson, 1823







reply via email to

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