Date: Wed, 19 Nov 1997 21:54:27 -0600 From: Richard Wackerbarth <rkw@dataplex.net> To: Brian Somers <brian@awfulhak.org> Cc: Annelise Anderson <andrsn@andrsn.stanford.edu>, freebsd-stable@freebsd.org Subject: Re: Version Resolution? Message-ID: <l03110700b0995d120c56@[208.2.87.4]> In-Reply-To: <199711200032.AAA12288@awfulhak.demon.co.uk> References: Your message of "Wed, 19 Nov 1997 15:05:28 MST." <199711192205.PAA06912@mt.sri.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 6:32 PM -0600 11/19/97, Brian Somers wrote: >The only way to get a reasonably useful date here would be to have an >automatic cvs posting on freefall every day to (say) sys/codedate.h: > > #! /bin/sh > mkdir /tmp/$$ > cd /tmp/$$ > for f in . RELENG_2_2 RELENG_2_1_7; do > cvs co -r $f -l sys > sed 's,\(#define __FreeBSD_codedate\).*,\1 '`date +%Y%m%d` \ > sys/codedate.h >sys/codedate.h.new > mv sys/codedate.h.new sys/codedate.h > cvs update -m 'Bump date' -l sys > rm -fr sys CVS > done > cd /tmp > rmdir $$ The problem with this is that the file (sys/codedate.h in your case) grows MUCH too rapidly for this to be useful. It also forces CTM to send out an update every time it runs, even if there are no other changes. My solution is similar. I do a pseudo update iff the branch has changed. Also, to avoid unreasonable growth of the file, I discard old values. This technique SHOULD get a useful resolution of a couple days. Because the updates and snapshots of the tree are async to each other, you cannot do any better except by reducing the granularity. Even if you reduce the granularity to milliseconds, there is always some uncertainty because the operations overlap. IMHO, a grain size of one day should be a reasonable compromise. For individuals who are not DIRECTLY accessing the master tree (which is MOST of the world), the technique works. There are two conditions that my code does not address. This is where Nate and I seem to differ. In my extended discussions with him BEFORE I wrote any of the code, we discussed these issues. I thought that he had agreed that they fell in the "nice, but not essential" category, and, as such, could be deferred to a later revision. However, since I finished the present version of the code only shortly before 2.2.5 was to be released, it was agreed that the time was not appropriate to commit the code at that time. Since, in Nate's opinion, there was time to do more, he unilaterally raised the requirements. Since I have not "solved" these additional problems, he seems to feel that my submission is unacceptable. The first involves the automatic recognition of new BRANCHES in the tree. This feature can be added. IMHO, this can aloso be handled manually for the present time. I have not seen more than about one or two new branches added in the same year. The second problem has to do with persons who DIRECTLY access the MASTER tree. I do not think that it is even possible to make the mechanism totally transparent for them. (Checking out the head of a branch and then tagging the tree does not produce the same result as you would get by checking out the tag at a future time.) However, I don't feel that this is important. The purpose of this mechanism is to differenciate different trees checked out by the same (head) tag. IMHO, anyone who falls in the DIRECT category or checks things out on the basis of a non-head tag should be able to make an appropriate characterization of the tree that they are using by some alternate means. This mechanism is intended ONLY for the benefit of those who need to have some idea of "which 'stable' (or 'current') system" is being used by the users who are simply tracking "the latest" of their intended branch. Richard Wackerbarth
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?l03110700b0995d120c56>