[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