Markus Kuhn wrote:
Martin Smoot wrote on 2000-07-28 15:39 UTC:
I recommend adding the date of the change to the data files. The africa data file for example only has the following at the top of the file:
# @(#)africa 7.33
The other data files also lack the date.
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps.
Markus
-- Markus G. Kuhn, Computer Laboratory, University of Cambridge, UK Email: mkuhn at acm.org, WWW: <http://www.cl.cam.ac.uk/~mgk25/>
"Joseph S. Myers" wrote:
On Fri, 28 Jul 2000, Markus Kuhn wrote:
I recommend to use RCS for revision control, which is today the de-facto standard, and supports even trendy ISO 8601 dates and UTC timestamps.
How about CVS, with an anoncvs server and so on?
There are services such as sourceforge.net providing CVS servers. And it should be possible to convert the existing revision control history.
-- Joseph S. Myers jsm28@cam.ac.uk
I think an automated method is the way to go too. One possible problem I can see with using an automated revision control system of any sort is that when the files are checked into yet another revision control system, the version number and date may be changed. we use CVS for our development and when the new timeline data files are downloaded and verified, we check them into our CVS repository. If the version number in the file is tagged so that CVS recognizes it, it gets changed to our current version number (1.5 for example) and date. as of now, the current version information is not touched by CVS when the files are checked in. There is probably a way with these systems to make the checkin use something other then $Log or $Id for the revision line (not obvious looking at man pages for cvs/rcs). If that is possible, they could be tagged with something like $TZ so that end users of the file do not have to worry about "trashing" the revision data. -- Martin Smoot Network Storage Solutions 703-834-2242 msmoot@nssolutions.com www.nssolutions.com