Stephen J. Turnbull wrote: Maybe it's me that isn't understanding. If I checkout the source tree using "-r r21-5-latest-beta" today I get 21-5-3 (unless it changed last night). Am I guarenteed that there will be *no* changes applied until you announce a 21-5-4? That I will *never* need to do cvs update until there is a new beta? If the last two statements above are *not* true, then I'm asking for a finer grained indication that I could feedback so y'all know precisely what source I'm working with when I report a problem. In the past I thought I had seen "cvs update -r r21-5-latest-beta" report some updates. -- David A. Cobb, Software Engineer, Public Access Advocate, All around nice guy. New PGP key 09/13/2001: :<http://pgpkeys.mit.edu:11371/pks/lookup?op=get&search=superbiskit&\ fingerprint=on> :<http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=superbiskit&\ fingerprint=on> Fingerprint=0x{E7C6_4EE2_6B75_5BA3_C52E__77FA_63C3_9366_DCFB_229B} "By God's Grace I am a Christian man, by my actions a great sinner." --The Way of a Pilgrim, R. M. French [tr.] Potentially Viral Software is any software for which you are not allowed to examine the source. Do not buy or use Potentially Viral Software!

On Tue, 20 Nov 2001 18:45:09 +0100, Adrian Aichner said: I think the complaint is that if you don't (for instance) write down the time, you may end up with some ambiguities. For instance, if I did a 'cvs update' night before last, but am just getting around to doing the build now, did I get some/none/all of the updates that Ben committed around the same time? A bit of poking indicates that 'ls -ldt CVS */CVS' will cough up the time that the last cvs operation happened. Not sure if that helps... ;) /Valdis

David> Precisely what I'm trying to pin down. Now, why "can't David> possibly?" version.sh looks like a very simple shell David> script - if you added a shell variable for the date and set David> it from `date` whenever a bugfix is applied, what component David> would even care? David, version.sh and all other files you update via CVS depend on WHEN and HOW YOU choose to update. You may apply patches or manual changes on top of that. What I am trying to point out: Only you can know what exactly you are building from. Know your sources :-) If you use straight-forward ways to update from CVS, like cvs update -r r21-5-3 then the thing to report is just that. I don't see a simple solution to this general problem. Best regards, Adrian David> OK, It need not be in version.sh, I'm just begging that it David> be somewhere in the tree where I can attach one simple file David> to a question/report and y'all will know *precisely* what David> my source-tree looked like when I built. David> Sigh! -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

Adrian didn't quite get the complete story out, but his last post was pretty close. David> Maybe it's me that isn't understanding. If I checkout the David> source tree using "-r r21-5-latest-beta" today I get 21-5-3 David> (unless it changed last night). That's correct and it hasn't changed. David> Am I guarenteed that there will be *no* changes applied David> until you announce a 21-5-4? Yes, in the following sense. When I do a release, I commit everything in the workspace. I do a cvs tag operation based on the revisions in my workspace with the r21-5-4 tag. I then do a cvs rtag operation that moves the r21-5-latest-beta from r21-5-3 (which stays the same) to r21-5-4. This means that if you use the tag, you can not see any commits that take place after my "canonical commit". David> That I will *never* need to do cvs update until there is a David> new beta? There are two exceptions. (1) A patch you really want was committed to the tip of the trunk. Then you use the -A flag to clear all tags and get the trunk. This is hazardous, because of "atomicity" issues and because people often commit stuff that isn't quite right. The real solution is for me/us to get off our duffs and release more frequently. We're aware of the problem and we're working on it. (2) CVS commits are not "atomic." This means that it is possible that while I am doing the tag operation, you start an update. Then it is very possible that you will be updating in a r21-5-3 directory, while I am tagging the files in another to be r21-5-4. In that case, doing an update with r21-5-latest-beta will get you a mixed checkout, very bad juju. This should be extremely rare. You can check it by waiting a few minutes and doing a second update or a cvs diff using the same tag. In fact, my release scripts do exactly that: repeatedly check out until no change is detected. David> If the last two statements above are *not* true, then I'm David> asking for a finer grained indication that I could feedback David> so y'all know precisely what source I'm working with when I David> report a problem. If you are using a tag, then we know exactly what you got from your Installation file. David> In the past I thought I had seen "cvs update -r David> r21-5-latest-beta" report some updates. Only if your updates bracketed a release, or the first update was interrupted and somehow incomplete. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

David> And you've given the answer I needed. If I say "r21-5-3" & David> "no local changes" you know precisely what my source tree David> looks like. There is no need to identify the date/time David> when I downloaded it. Right. I'm sorry it took so long to reach a meeting of minds. Just goes to prove, concurrency is HARD. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.