[Apologies if this is a repost, posting thru egroups.com has failed twice]
Hello,
I'm a long-time satisfied user of CVS remotely via
SSH. I would like to enhance CVS to overcome a
particular deficiency, but first I wanted to hear
what the CVS "pros" think. That means you! :-)
The basic problem is that detecting file changes
by storing timestamps in the CVS/Entries file is
prone to error.
When the CVS client "update"s a file, the
timestamp of that file is stored in CVS/Entries.
When a new update is performed (or something else
like the up-to-date check when checking in), the
CVS client compares the stored timestamp with the
file timestamp, and uses this as an indication of
whether it should contact the server and request
the unchanged version.
The problem is that just using the timestamp is a
poor indicator of whether the file has changed.
- Due to copying between machines (Windows!), the
timestamp may not be the same any more, although
the data is.
- The file may have changed (somehow) but the
timestamp is the same (much less common).
My suggestion is, instead of storing the timestamp
in CVS/Entries, the CVS client stores the MD5 of
the file. And the up-to-date check performs an
MD5 of the file. If they don't match, the CVS
client knows beyond all doubt that the file has
changed, and can contact the CVS server.
To see why this is needed, imagine you have a 50mb
repository, you're connected over a modem, and all
your files have been touched. With the present
timestamp system, "cvs up" is going to take a
LOOOONG time... :-)
Making this change seems worthwhile, doesn't seem
overly hard, doesn't change the CVS paradigm and
doesn't change the CVS client/server protocol.
(And CVS already includes the MD5 code...)
So could people tell me whether or not
this is a good idea please?
All responses will be most gratefully received.
Regards,
Mitch.
--
| mailto:[EMAIL PROTECTED] | Not the official view of: |
| mailto:[EMAIL PROTECTED] | Australian Calculator Opn |
| Certified Linux Evangelist! | Hewlett Packard Australia |
