How Bazaar works

[Daniel Carrera]

Hi Stephen,

Thanks for the reply. I am not an expert at SCMs, but I did have the 
strong feeling that the OPs were talking nonsense. Between your email 
and their follow-up posts, I am now sure that they're talking nonsense.

Poster #1:

~/B $ darcs initialize
~/B $ darcs pull ../A
~/B $ touch 3
~/B $ darcs add 3
~/B $ darcs record
~/B $ rm -r ~/A
~/B $ darcs push
<error>

And then says that the branches are not independent. Ugh. The thing is, 
he really thinks that doing this means that you've lost work and that B 
is now in a broken state.

The second poster basically has the same misunderstanding. He thinks 
that when you clone or pull you are not making a branch (he says that 
it's not a branch until you commit something new) and that you have a 
dependency with the "parent". So they are thinking more like "light 
weight branches" and don't realize that this is not how other SCMs work 
by default.


Anyways, thanks a lot for helping me understand this.

Cheers,
Daniel.


Stephen J. Turnbull wrote:
> 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?
> 
> 
>