On Tue, Nov 3, 2009 at 10:10 PM, Ben Goodger (Google) b...@chromium.org wrote:
Can there be a way to apply this to a local tree only so that you can revert
then revert the revert quickly locally so you can figure out why your change
broke?
I know this doesn't answer the question you are
Drover is actually an order of magnitude faster than a standard svn
merge/reverse, merge since it only affects the files that are involved with
the CL (as opposed to trying to descending the entire trunk). A normal
merge would take in the space of 8 minutes on my box (which required an
existing
Interesting. WebKit has similar functionality as:
bugzilla-tool rollout 12345
We've found that git reverts are at least an order of magnitude faster
than SVN reverse merges.
I wonder what bugzilla-tool/drover can learn from one another.
-eric
On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain
I tried that a few days ago, and drover died with me with something
along the lines of Can't talk to chrome-svn (which as far as I
understand is some internal svn repo?). A quick glance at the source
confirms that this is still the case.
On Tue, Nov 3, 2009 at 1:53 PM, Nicolas Sylvain
On Tue, Nov 3, 2009 at 3:01 PM, Nico Weber tha...@chromium.org wrote:
I tried that a few days ago, and drover died with me with something
along the lines of Can't talk to chrome-svn (which as far as I
understand is some internal svn repo?). A quick glance at the source
confirms that this is
Yeah, does anyone know why SVN does that? It seems like it could easily
inspect the revision to see what files changed, and then only merge those
files :-/
depot_tools/revert also works this way. Should we remove
depot_tools/revert, or re-implement it on top of drover?
-Darin
On Tue, Nov 3,
