Closed Bug 79280 Opened 24 years ago Closed 23 years ago

Mac build system should have a fast_update option


(SeaMonkey :: Build Config, defect, P4)

Mac System 8.5


(Not tracked)



(Reporter: sfraser_bugs, Assigned: sfraser_bugs)



(5 files)

Having a fast_update option in the Mac build scripts, that queries Bonsai to get 
the list of files to update, would be cool.
With these changes, and a new version of MacCVS Pro (which you can only get by 
building the MacCVS Pro tip right now), you can do fast_update by setting 


in your build prefs. This acts as follows:
* If you've never checked out before, or the stored checkout time file does
  not exist, it does a normal checkout
* If you last checked out more than a week ago, it does a normal checkout.

It stores the checkout timestamp in a file called 'Last update time' in the tree 
root dir. This file contains an Epoch seconds value (hence GMT). The script 
always checks out files checked in during the last (1 + (hours diff)) hours, to 
ensure that no files are missed.

Bad things about this page (some are shared with fast_update on other platforms)
1. It only checks out files checked into the tip (i.e.not NSPR etc)
2. It puts build-specific logic in a file that is supposed to be build-agnostic
3. 'Last update time' is a bad name for the file.
4. Having fast_udpate on for the commercial build probably doesn't work.

Hey, but it's a start!
Attached patch Better patchSplinter Review
Last patch removed debugging cruft, fixes filename, and stores the time at the 
_start_ of checkout/update.
Priority: -- → P4
Target Milestone: --- → mozilla0.9.2
-> mozilla 1.0
Target Milestone: mozilla0.9.2 → mozilla1.0
That last patch does a fast-update on each module in the MozillaCheckoutList.txt 
file, ignoring modules that are pulled by date, and using the branch tag as 
appropriate. I declare it finished.

Note that for it to work, you have to have a recent MacCVS Pro build (2.7d7 or 
170 hours is the magic number limit of Bonsai's memory?  Maybe a comment should
say that.  In any case, sr=scc.
No, 170 hours was pulled out of a hat (it's about a week). I just thought that 
doing a fast_update over any longer time-period than that was probably not 
reliable. I'm not sure how reliable bonsai is -- leaf/endico?
i know there are at least a few checkins missing from the bonsai database that
would get missed if you went back all the way to the beginning of the bonsai
database, but other than the risk of missing those, i don't think there is time
limitation to the checkins that bonsai has tracked.

The unix version of only checks the last 24 hours of changes, so
the concept of "last updated" being stored in the local tree is a vast improvement.
The latest two patches are my Final Answer on this bug. They deal with storing 
the last pull date separately for mozilla and netscape pulls.
+    print(TIMESTAMP_FILE "# time of last checkout or update, in GMT. Use by

should be

+    print(TIMESTAMP_FILE "# time of last checkout or update, in GMT. Used by

Other than that, r=peterv.
So all we need to put this into general practice is (a) to check these files in
and (b) to provide a build of MacCVS Pro that has the associated machinery?
Yes. I'll get a Mac CVS Pro 2.7d8 out (tho I think 2.7d7 has the necessary code). 
I guess I need to check that the MacCVS which is running is studly enough to 
support the fast_update.
sr=scc on the most recent two attachments above (i.e., 41299 and 41300)
Checked in.
Closed: 23 years ago
Resolution: --- → FIXED
over to jj for verification.
QA Contact: granrose → jj
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.