<div dir="ltr"><div><div><div><div>I think we have 3 issues that drive up diff size:<br></div><div><br></div>1) Bzr has branches, but they aren't cheap enough. The simple fact that you have to compile each branch in its own directory is too big of a cost to branch as often as I would in git. Furthermore, as illustrated by the conversation above, if you want to split, you can't cherry pick and rebase very easily, you end up doing a lot of patchwork, and loosing chunks of time if something goes wrong.<br>


</div><div><br></div>2) For some features, we have a relatively high 
testing burden. Namely, if we're tinkering with code that touches the 
hardware, we have to test across a bunch of devices manually. My current
 'full test' that we do for hardware changes is effectively 6 devices, 
and only going up from there! If you have to set up 6 devices, you've 
likely burned 2-3 hours in setup time (much more if there's a problem, 
if you have to build the full unity stack, or if your download speed is 
slow). This is obviously not required for all branches, but on the 
branches that it is necessary, its only natural to try to save testing 
time by batching the manual testing work.<br>
<br></div>3) When we have a smaller review, and something crucial 
is found wrong with the first one, then the subsequent patches all need 
tedious updating and re-testing. Our team has a lot of very good 
reviewers, and most the time something needs changing, causing this 
cascade to the other branches. <br>
<br>Another point to make is that diff size alone is a misleading metric in judging the effect of a 
change. If we add a stub and mock in the course of writing a branch, 
that alone drives 'the diff size' up 150-200 lines, even though this is 
easy to review. A new test file drives up the diff size a lot too. 
Furthermore, renames really drive up the diff size, as there are many 
places that need updating. <br>
<br>My main take-away point is that although small branches are more 
pleasant to review, there are pretty good time-saving reasons for the 
proposer to batch some of the changes.<br><br></div>Cheers,<br>Kevin<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 28, 2014 at 2:35 PM, Christopher James Halse Rogers <span dir="ltr"><<a href="mailto:raof@ubuntu.com" target="_blank">raof@ubuntu.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Tue, 2014-01-28 at 12:32 +0100, Marco Trevisan wrote:<br>
> Il giorno mar, 28/01/2014 alle 14.47 +0800, Daniel van Vugt ha scritto:<br>
> >    1. Create a diff: bzr diff --old :parent > ~/bigone.diff<br>
> >    2. Create a new branch and reapply the changes:  patch -p0 <<br>
> > ~/bigone.diff<br>
> >    3. Identify changes to drop: bzr status or bzr diff<br>
> >    4. Drop them: bzr revert path/to/files<br>
><br>
> Instead of doing this manually, line per line, I think that bzr<br>
> (q)shelve can be very useful to stash chunks of sub-file changes in a<br>
> quicker way... BTW I wish we had something like bzr add --patch :(<br>
<br>
</div>Isn't “bzr shelve” the (almost exact¹) dual of what “bzr add --patch”<br>
would be?<br>
<br>
¹: The thing that I miss from git add -p is the ability to split hunks<br>
of diff. This shouldn't actually be hugely difficult, but I've never got<br>
around to fixing it.<br>
<br>--<br>
Mir-devel mailing list<br>
<a href="mailto:Mir-devel@lists.ubuntu.com">Mir-devel@lists.ubuntu.com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/mir-devel" target="_blank">https://lists.ubuntu.com/mailman/listinfo/mir-devel</a><br>
<br></blockquote></div><br></div>