How Bazaar works

Neil Martinsen-Burrell nmb at wartburg.edu
Thu Jan 21 15:04:38 GMT 2010


On 2010-01-21 06:38 , 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).
>
> 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>
>
>
> This doesn't sound right. The idea that each branch is dependent on
> another branch, forming some sort of DAG tree, seems wrong. I expect
> that in any decent distributed SCM, each branch is equal and
> independent. So if you create branch A, then from there create branch B,
> from that point on B is totally independent on branch A, and it doesn't
> matter if you delete A.
>
> When I expressed my doubt that distributed SCMs work like this (I know
> that Darcs doesn't) another poster assured me that this is true:

This is my attempt to render the OP's comments into Bazaar commands. 
Note that the presence of a remote repository is irrelevant to the 
result here so I haven't created one.

nmb at guttle[~]$ cd tmp
nmb at guttle[~/tmp]$ rm -r A B
nmb at guttle[~/tmp]$ bzr init A
Created a standalone tree (format: 2a)
nmb at guttle[~/tmp/test]$ bzr checkout --lightweight A B
nmb at guttle[~/tmp/test]$ cd B
nmb at guttle[~/tmp/B]$ bzr info
Lightweight checkout (format: 2a or development-subtree)
Location:
   light checkout root: .
    checkout of branch: /Users/nmb/tmp/A
nmb at guttle[~/tmp/test]$ cd ..
nmb at guttle[~/tmp]$ rm -r A
nmb at guttle[~/tmp]$ cd B
nmb at guttle[~/tmp/B]$ bzr info
bzr: ERROR: Not a branch: "/Users/nmb/tmp/A/".

Note the use of checkout --lightweight to "clone" a working tree that 
points to the repository in A.  However, if we use Bazaar's default 
"branch" command, then there is no problem because B has its own copy of 
the revisions.

nmb at guttle[~/tmp/B]$ cd ~/tmp
nmb at guttle[~/tmp]$ rm -r A B
nmb at guttle[~/tmp]$ bzr init A
Created a standalone tree (format: 2a) 

nmb at guttle[~/tmp]$ bzr branch A B
Branched 0 revision(s). 

nmb at guttle[~/tmp]$ cd B
nmb at guttle[~/tmp/B]$ bzr info
Standalone tree (format: 2a)
Location:
   branch root: .

Related branches:
   parent branch: /Users/nmb/tmp/A
nmb at guttle[~/tmp/B]$ cd ..
nmb at guttle[~/tmp]$ rm -r A
nmb at guttle[~/tmp]$ cd B
nmb at guttle[~/tmp/B]$ bzr info
Standalone tree (format: 2a)
Location:
   branch root: .

Related branches:
   parent branch: /Users/nmb/tmp/A

Note that no contact is necessary with the remote branch (no network 
activity, fast on-disk transfers).

> <quote>
> When you clone REMOTE to A, a note is made in A that you cloned from
> REMOTE. So when you are working in A and you push or pull or sync it
> knows that the endpoint of that operation is REMOTE.
>
> When you clone A to B, a note is made in B that you cloned from A. So
> when you are working in B and you push or pull or sync it knows that the
> endpoint of that operation is A.
>
> Then you delete A. And you go into B and make some changes, and commit,
> and push. And it says "Can't. A is missing". And you have to
> explicitly tell it that you want to sync with REMOTE instead of A.
> </quote>
>
>
> On a second reading, maybe the guy is just saying that when you push you
> have to put the URL of the repository you are pushing to. If so, that's
> not a dependency!

I believe that this is the point: the parent location of B does still 
point to A, but that is easy to change.  I'm not sure what would be a 
better choice.  If B's parent was A and A no longer exists, then B needs 
to be given a new parent location.

-Neil



More information about the bazaar mailing list