For Developers‎ > ‎How-Tos‎ > ‎

How to use drover - Temporarily Out-of-Order, due to Git migration.

What is Drover?

Drover is a tool, which is 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.

Requirements/ recommendations

  • Drover requires SVN 1.5+
  • depot_tools should be on the default path
  • When you first start using drover, it's best to start in an empty directory since it creates unique subdirectories for each revision it merges/reverts to pull down the necessary files to update.
  • You'll need your svn username and password (for svn checkouts)
  • You'll also need your chromium.org credentials (for code reviews)

Usage

  • Revert on trunk
    • drover --revert <svn revision> (e.g. drover --revert 12345)
  • Merge a change to a release branch
    • drover --merge <svn revision> --branch <branch_id> (e.g. drover --merge 12345 --branch 249)
  • Merge a change between release branches
    • drover --merge <svn revision> --sbranch <src_branch_id> --branch <dest_branch_id> (e.g. drover --merge 12345 --sbranch 249 --branch 249)
  • Merge a change to your local copy
    • drover --merge <svn revision> --local (e.g. drover --merge 12345 --local)
  • Revert a change on a release branch
    • drover --revert <svn revision> --branch <branch_id> (e.g. drover --revert 12345 --branch 249)
Note: If you include --auditor <someone@chromium.org> it will automatically set that person as the reviewer

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.

Dealing with conflicts

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:
  • Mark any conflicts that svn finds as "postpone" (aka "p")
  • Once you get to the prompt "Do you want to upload", drop to another shell/ command window (you could also upload here, and resolve before conflict)
  • cd to the directory where you ran drover, under their you will find a sub directory for the revision you just checked out (e.g. drover_12345_249)
  • cd into that drover_* directory
  • Resolve all merge conflicts (a good diff tool, text editor, svn resolve, and svn resolved are you friends)
  • All normal svn and gcl commands will work in there (the gcl change is always stored as the revision, e.g. gcl submit 12345 for the previous case)
  • After you resolve the conflicts you can return to the original shell, do the upload and then commit

Blink Merges

Use the following steps:
  1. Create a new directory specifically for blink merges.
  2. In that directory, run svn export https://src.chromium.org/blink/branches/chromium/drover.properties. This will create the configuration file you need.
  3. Now just do one of the regular drover commands above. The <svn_revision> you specify will refer to the blink svn revision, for reverts it's just the svn revision you landed on to the branch.

So how does Drover work, why is it so much faster than normal merges/ reverts?

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.

A slightly more technical explanation of this black magic

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.
Comments