On Sun, Oct 9, 2011 at 10:03, Lester Caine <lester@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 users... 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 -- Kevin Lyda Dublin, Ireland US Citizen overseas? We can vote. Register now: http://www.votefromabroad.org/