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 (Sep 5) git-drover is not available. Follow https://code.google.com/p/chromium/issues/detail?id=404755 for updates.
*** IF YOU ARE TRYING TO MERGE STUFF FOLLOW THE ONLINE GIT-DROVER DOC LINK FOR THE NEEDED STEPS UNTIL GIT-DROVER WORKS ***
Until the git-drover tool is available, please see
Note: If you include --auditor <firstname.lastname@example.org> 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.