data file recommendation

[Martin Smoot]

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 at 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 at nssolutions.com         www.nssolutions.com