How Bazaar works

[David Ingamells]

Daniel Carrera wrote:
> Hello,
>
> I'm on the mailing list of another DVCS called fossil and someone there 
> made a comment about other DVCS tools which doesn't sound right at all:
>
> <quote>
> Consider the case of hg or darcs or some other such distributed system 
> which conflates the repository and the working set.  I'm working on a 
> project, so I clone a remote repository into a local directory.  I make 
> changes to feature A.  While I'm working on A, I get a high-priority 
> request to work on feature B.  Either I clone the remote repository 
> again (needs network, needs time, hits the remote server harder in a 
> large project, wastes space as the repository itself is recopied, etc.) 
> or I clone my local copy in A (which just wastes the space).
>
>   
That's how our teams works with bzr. One task == one branch. Our 
situation is slightly different in that the central repos is local so
we all branch directly from that:

e.g.
task A
     branch from central repos (ideally stacked)
     edit, edit ...

task B
     branch from central repos (ideally stacked)
     edit, edit ...

task A done
     commit, delete.

task B
        edit, edit ... no worries :-)

If the main repos is remote then I believe the only change needed is to 
make and maintain _one_ full local branch and to checkout/branch 
(lightweight or stacked [current bug in 2.0.3 allowing]) from that for 
your tasks. These task checkouts/branches are small and fast to create.

David.

> Let's say we took the second option.  While I'm working in B, I finish 
> my work in A.  I push my changes and delete A ... and WHOOPS!  I just 
> screwed up B, didn't I?  B is expecting A as an uplink which is now gone 
> because the distinction between the working set and the repository is 
> fuzzy.  I can reseat B to point to another copy of the repository (and 
> hope that that repository doesnt' have changes which clash with the 
> changes I made in A and in B) but I think anybody can see that this is 
> not a particularly good solution.
> </quote>
>
>   
Don't know enough about bzr internals, but I'd expect bzr to be able to 
cope with that.