Bazaar Workflow

[Philippe Lhoste]

On 05/04/2009 16:20, 马旋（SuperMMX） wrote:
> If you have uncommitted changes in your working tree, it is not in a 
> clean state to merge, because merging will change the working tree,
> IMO, it is not that obvious to look at the merge result. 

Well, I do that a lot at work (with Perforce). While I work on my files, I pull the latest 
changes by my co-workers. If a file in check out have been changed on the repository, I am 
warned (red icon) and I have to do a manual resolve (using Perforce Merge, a good tool) to 
ensure my current un-committed code works fine with latest code. As long as it is manual 
(ie. I see all changes), it seems pretty safe.

On 05/04/2009 20:52, Neil Martinsen-Burrell wrote:
 > I see the following in a similar test, starting from scratch:
[...]
 > nmb at guttle[/tmp/new]$ bzr merge
 > bzr: ERROR: Working tree "/private/tmp/new/" has uncommitted changes.

Aha! I see the difference between your test and mine!
You do a bzr merge when I do a bzr pull, which performs automatically a merge, as it seems 
(quietly if no conflict, creating the usual suspects if there is one).
The pull seems close of my Perforce workflow...

Being a Bazaar newbie, I am still unsure of the nuances between pull and merge in this use 
case. [Looking again at Reference...] Ah, it looks like merge --force acts a bit like 
pull, except not trying to do an automatic merge, even if there are no conflicts. So in 
both case we can do an update of the un-committed changes. Which is a Good Thing(TM) as 
long as it is done well... :-)
Ah, and after merge, we still have to commit changes, while pull does all this in the same 
stroke.

I haven't tested yet with diverged branches...

-- 
Philippe Lhoste
--  (near) Paris -- France
--  http://Phi.Lho.free.fr
--  --  --  --  --  --  --  --  --  --  --  --  --  --