<p>Sorry for mail format, replying on phone during a break in class. In the past ado has incremented the sccs release number. There was a reset of all numbers to 8.1 at one point for instance.</p>
<p>Based on the sccs tools that would be easier for him to important changes made in his absence.</p>
<p>I can redo my patch if you would like.</p>
<div class="gmail_quote">On Oct 10, 2011 8:17 PM, "Robert Elz" <<a href="mailto:kre@munnari.oz.au">kre@munnari.oz.au</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Date: Mon, 10 Oct 2011 18:42:16 +0200<br>
From: David Zülke <<a href="mailto:david.zuelke@bitextender.com">david.zuelke@bitextender.com</a>><br>
Message-ID: <<a href="mailto:D6D084ED-BABA-4BF7-BA4F-69CA4C3FC41A@bitextender.com">D6D084ED-BABA-4BF7-BA4F-69CA4C3FC41A@bitextender.com</a>><br>
<br>
| You did not increment the version numbers in the files you changed,<br>
<br>
Ian Abbott indicated the source of those, but not withstanding that, I could<br>
have updated them (manually) I just decided not to, for now. However, if<br>
having those version numbers updated is useful to people (and I know they have<br>
been used in the past to confirm that you are at the latest version in<br>
case of apparent discrepancies) I can do it - if that's what people prefer.<br>
<br>
I can see three ways (and there could of course be more) that that could be<br>
done - aside from just doing nothing ... First, would be to pretend to be<br>
sccs, and produce numbers indistinguishable from what it would produce.<br>
Second, would be to modify the numbers in a way sccs would not, but still<br>
allow them to move "forward" - the easy way to do that would be to append<br>
a sub-version number (making say 8.50.1 for northamerica) and just<br>
continue from there, leaving 8.51 for ado's next version, if that ever<br>
happens. [Aside: yes, I know a sccs branch could produce a number like that,<br>
but the tz files have no branches, and in any case, sccs would add 2<br>
sub-version numbers, I believe, never just one.] Or, third, I could insert<br>
my owv version numbers to run in parallel - I have the data in RCS files<br>
(just for convenience, some of you probably already detected that from looking<br>
at the precise details of the diff I sent out) and RCS has its own version<br>
numbering scheme, I could just add those version numbers (they they could be<br>
removed again sometime later).<br>
<br>
Which do you all prefer?<br>
<br>
Řyvind Holm <<a href="mailto:sunny@sunbase.org">sunny@sunbase.org</a>> said:<br>
| But I notice there's lots of unrelated files and directories in the pub/<br>
| directory. Would it be possible to move the files into a separate tzdata/<br>
| directory<br>
<br>
Of course, it would be possible, but for now I don't think I'll do that.<br>
As much as possible I'd prefer to retain as much of the style of ado's<br>
distributions as possible - they were in pub at elsie, the files have also<br>
always been in pub on munnari, I think just leaving them in pub on munnari<br>
is adequate for now. After all, at least for now, there are just two files<br>
(and later perhaps 4 if/when we add detatched signatures).<br>
<br>
The oldtz directory is just for us here, no normal humans should be going<br>
near it, it is of sudden interest only because people have been (quite well<br>
it seems) looking for methods to re-create ado's sccs database (in other<br>
version control systems) and so need access to all the earlier data. That's<br>
fine (for that purpose, or just to retain it for posterity) but it isn't<br>
something that should, or rationally would want, to otherwise be widely<br>
distributed.<br>
<br>
And lastly Kevin Lyda <<a href="mailto:kevin@ie.suberic.net">kevin@ie.suberic.net</a>> said:<br>
| There are several places in the code that refer to the ftp server and<br>
| mailing list on elsie.<br>
<br>
I suspect the elsie mailing list is dead forever now, and the iana version<br>
will take over, so those changes (thanks for the patch) make sense. I'm<br>
not sure yet about the source repository doc changes, why not just wait<br>
a little longer until we see how the dust settles on that before we<br>
start documenting the current (temporary) arrangements ?<br>
<br>
kre<br>
<br>
<br>
</blockquote></div>