[Bug 4741] bzr shelve is confusing to me

[Brad Bollenbach]

On 24-Nov-05, at 4:38 PM, Matthieu Moy wrote:

> Brad Bollenbach <brad.bollenbach at gmail.com> writes:

>> I could also commit first instead, which I sometimes do, but I like
>> to try and keep my commits pretty clean
>
> You have this problem because you "undo+merge+redo" at a moment when
> your tree is not "clean". Well, there are probably some arguments in
> favor of this, but I think your version control commands should be
> driven by your work, not the upstream work. If you started something,
> then finish it first, then commit, then merge.

bzr is my slave, not my master. :)

This workflow (move changes aside, merge in upstream changes, move my  
changes back into tree) worked nicely, albeit very slowly, in baz. It  
should continue to work in bzr, IMHO.

> If you have something long to implement, and you want to merge several
> times before commiting, then microbranches are for you (and inside a
> microbranch of your main branch, you can "pull" which does roughly
> what you describe. Then, the main branch can also "pull" the
> microbranch).

For a bzr implementor, I'm sure the thought of microbranching here is  
extremely elegant. Don't Make Me Think:

     http://tinyurl.com/72wl7 [amazon.com]

:)

>> rather than, for example, committing debugging code.
>
> If you have debugging code in your tree, it means there's something in
> your code that you don't understand. Incorporating upstream changes at
> this momend does not seem to be the best thing to do. Moreover,
> there's a risk of conflict in the debug code itself that you wouldn't
> have had if you had finished your task before merging.

I had this workflow available to me in baz, and used it often. It  
would be useful (to me, at least) if this workflow continued to be  
possible (and perversely simple) in bzr.

Cheers,

--
Brad Bollenbach