Drover is a tool, included with depot tools, that allows developers (should be a committer) to rapidly merge and revert changes on our svn trunk/branches without any previously checked out working copy. A typical drover command merge/revert with no conflicts, takes about 1 minute to run from start to finish.
Merging to a branch and don't know the branch number? The TPM (release manager) approving the merge will have it.
After merging to a release branch, try to watch http://go/stablebuilders (for stable branches) and http://go/branchbuilders (for dev/beta branches) to make sure everything's all right.
As of today (October 6, 2015) git-drover is available for Linux and Mac. Follow https://code.google.com/p/chromium/issues/detail?id=404755 for updates.
For merges on Windows and reverts, please see
If this is the first time you've tried to merge into a branch, you may run into the following error when trying to git cl land the change:
error: failed to push some refs to 'https://chromium.googlesource.com/a/chromium/src.git'
ERROR:git-retry:Process failure was not known to be transient; terminating with return code 1
Push failed with exit code 1.
! HEAD:refs/pending/branch-heads/2311 [remote rejected] (prohibited by Gerrit)
If you see this error, you may not have been added to the chromium-committers gerrit group. File a bug with the Infra-Git label.
Merging Blink revisions into branches using git
NOTE: this is only needed for branches older than M46. As of M46, Blink is merged into Chromium.
Note: If you include --auditor <email@example.com> it will automatically set that person as the reviewer
Conflicts are a natural part of the merging process, especially as the trunk drifts further away from the branch. Fortunately Drover makes this fairly manageable to resolve, since the tool does all its work in subdirectories under the working directory it was run in (e.g. if you did drover --merge 12345 --branch 249, the working directory it would create would be ./drover_12345_302). Under that directory you will find all of the source files that drover attempted to update in the change. So, with that bit of knowledge in mind, the resolution process goes something like this:
The short answer is that a normal merge would 1.) Require that you to checkout *all* of the code using SVN, even if it wasn't being affected by the merge (I've seen this take 1+ hours) 2.) When the merge was applied it would scan all of the code for history/properties changes, even if nothing changed (I've seen this take 10+ minutes for a one line change) 3.) Require that you do separate gcl commands.
Drover short circuits this by 1.) Only checking out the files/directories on the branch that were involved with the CL that's being merged/reverted 2.) Applies the merges directly to these affected directories individually (i.e. it doesn't let svn creep around the entire code-base). 3.) It integrates with gcl, so when you do the upload it pre-populates the comments and automatically sends the code review to the author of the cl.
The shallow checkout is accomplished by recursively building the directories using a combination of svn co --depth empties (which is why it requires svn 1.5+) and then svn updates to specifically pull the files affected by the merge. Next it applies the svn merge command to the individual directories (note: not the files) with instructions not to traverse children, which keeps the scope of the merges small. Since it kept everything in a single working copy regular svn/gcl commands work like normal on it.
Testing a merge
The trybots and commit-queue cannot handle merges, so you might want to try to compile locally before committing. Here is a way:
// check out the release branch as per above
// do your merge
$ gclient sync --jobs=20 --force --revision src@HEAD
// check out the Blink branch as per https://docs.google.com/document/d/11o74oGwPkA58HBIZlDDV_CEbf3r-eUz_PDAh-DyH9iw/edit#heading=h.87eks4ierg7d
Now build as usual.