[tz] A history maintaining repository for tzdata

Kevin Lyda kevin at ie.suberic.net
Sun Oct 9 10:47:07 UTC 2011

On Sun, Oct 9, 2011 at 10:03, Lester Caine <lester at lsces.co.uk> wrote:
> Kevin Lyda wrote:
>> BTW, it appears that this will work best with the data and the source
>> in one repo as that's how the releases were originally done.

I really can't decide on this one.  It really looks like ado keeps the
whole thing in one directory and has maintenance scripts that generate
the tarballs.

What I'm leaning towards is starting with them all in one dir and
then, withe the initial 1993 release moving to having them in tzcode
and tzdata.

It might make the migration of the sccs history a bit harder, but I
think it will better reflect what is happening.

> Moving forward, separate repo's make a lot more sense? The code is still
> version 'g' this year, while the data has moved on. No need to have to
> 'release' new code copies with every data update.

There will be a separate commit for each tzdata and each tzcode release.

> Of cause if the releases are dropped altogether, and only the repo is
> supported, then a single point makes sense, but personally I'd prefer to see

Absolutely not - it would be insane to get rid of tarballs (or some
package format - the initial releases were shar and patch so it's
changed over time).  I just want the history of the project
maintained.  First because I like history but also because having the
complete history in one easy to view place might be of assistance to
ado and eggert (that's why I've made sure to reference sources in each
commit message).

Part of that history is the tarballs (and shars and patches)
themselves.  So they should definitely be maintained.  And obviously
they're very useful for end-users for future releases.  This is just
for "digital historians" (or whatever such a field will be called) and
a possible base for future maintainers of the code/data.

> 'packaged' data releases since git is not the best of bases for DVCS and
> hopefully a much more generic base will develop ... getting git on a windows
> machine still needs to be made a bit more reliable!

I have never really used Windows so I was unaware of this issue.  I
actually started using DVCS with hg, but trends really seem to be
favouring git over hg and bzr from what I've been reading.  I don't
want to start a VCS war though so I can look at providing both a git
and hg repo (I think the migration from git to hg is pretty simple).
I could put both up onto bitbucket.org - they now support both
formats.  And a Windows version would likely be very useful for legal
assistance reasons - I suspect lawyers and judges might not be Unix

I'll offer this suggestion however.  I do all my work on an OS X box.
While OS X has unix roots its fs is not case sensitive.  At times
that's an issue.  So to avoid that I generally use VirtualBox and some
handy Linux distro (lately Debian or Ubuntu since my employer uses
those) to do actual work on unix-related projects.  Machines are fast
enough these days that it's as fast as I need it to be.


Kevin Lyda
Dublin, Ireland
US Citizen overseas? We can vote.
Register now: http://www.votefromabroad.org/

More information about the tz mailing list