blob: 4c47b1e27e4c2686e6cc93bec5770407bbf2d12c [file] [log] [blame]
You want to be very careful about updating the reference builds, because it
means changing the baseline all new builds are compared to on the performance
graphs and can easily let regressions slip in.
The Chromium and Google Chrome builds the same revisions so you can compare
Google Chrome and Chromium performance data.
For the Chromium build, just take a build off the waterfall's continuous
builds, that way it is know to have passed tests, etc. Download the zip,
and to get it into svn:
1. Use rsync to get the file tree updated to the current layout:
rsync -r -C --delete \
[path_to_new]/ \
2. Use svn stat to figure out what needs to be added/deleted:
svn stat src/chrome/tools/test/reference_build/chrome_mac/
a. Anything with a status of "!" you need to svn remove (usually the old
version directory is the only thing)
svn remove[old_version]
b. Anything with a status of "?" you need to svn add (usually the new
version directory is the only thing). Remember to use --no-ignore so
any binary files svn might try to ignore get included (.so, .dylib,
svn add --no-ignore[new_version]
Since there usually isn't an official build with exact same revsion, you have
to do that yourself ("branding=Chrome buildtype=Official").
Once the build is done, remove the keystone framework and plist keys so when
it is used by tests, it won't try to keep it self updated.
rm -rf \
"Google[new_version]/Google Chrome Framework.framework/Frameworks/KeystoneRegistration.framework"
From both the app and framework Info.plist:
"Google Chrome Framework.framework/Resources/Info.plist"
remove the Keystone entries:
Then repeat the rsync/svn remove/svn add steps that were done with the Chromium
app, but with the Google Chrome app instead.
Finally commit these changes and you'll then need to roll src/DEPS to to pull
in the new reference builds.