How Bazaar works

[Stephen J. Turnbull]

Daniel Carrera writes:

 > <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 nonsense.  *All* of the major OSS DVCSes (git, Mercurial,
Bazaar, and I think even Darcs) have *several* strategies for
lightweight branching.  git and Bazaar have shared repos and some sort
of colocation of branches in a single workspace (this is important in
a big project because you can often reuse many of the checked out
files because they're identical, and build products for unit testing
during development -- of course before pushing B, you probably want to
do a full build and test).  git, Mercurial, and (I think) Darcs will
hard link the revision library (or patch library for Darcs).  As
described below, git, Bazaar, and Darcs support some form of shallow
clone (but please don't ask me why you would want a shallow clone on
the same host :-).

 > 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.

Aha!  I think this person hasn't used a DVCS developed since Arch! :-)

 > 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.

That's true if you do a full clone of the branch.  However, all of the
major DVCSes (except maybe Mercurial) support some kind of shallow
clone (git clone --depth, bzr branch --stacked, bzr checkout
--lightweight, darcs get --lazy).  It's possible to shoot yourself in
the foot this way, especially with Darcs.  But in most workflows
involving shallow clones, the source is the trunk or a mirror; hardly
something you're likely to delete, and (because of the "D") it is
extremely likely that there are multiple clones of the source lying
around for anything you might want to shallow clone in practice.

 > 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 don't know what he intended to say, but that is indeed what he
said. :-)

How does fossil avoid that?