bzr overview questions.

[Rob Browning]

jblack at merconline.com (James Blackwell) writes:

> Tags can mean one of two things. The first is the storage of file
> identifiers in files (as bazaar and arch support). The other is a limited
> form of branching.

Ahh, right.  I was thinking of the latter, in particular, tagging
releases.

> In the bzr world, users are encouraged to branch early and often, such as: 
>
> $ ls project-head
> [ here is my source code]
> $ bzr branch project-head  project-neatfeature 
> $ ls project-neatfeature
> [ here is the same source code again. You can work on this an commit to it
> individually, later merging it back to project-head]

So does bzr hard link by default in this situation, or do you need cp
-al for that?

> bzr couldn't care less. If you mv ThisIsMyBranch into /tmp, you can still
> cd into the directory and hack and commit.

OK.  Actually, I don't think I asked the question I meant to ask.
What I was really wondering about was what how bzr handles things like
ancestor archives "going away", projects and/or branches being
renamed, etc. (c.f. Arch).

> Also, one can branch by simply performing a cp -a:
>
> $ cp -a project-head project-feature
> $ cd project-feature
> hack, hack, hack commit. hack, hack, hack commit.
> $ cd ../project-head
> $ bzr merge ../project-feature

While the simplicity with which bzr handles this sort of thing is
nice, I suppose you have to take a bit more care with your
trees/archives.  For example, if you have 50 releases of a given
project, you'll need 50 full trees, and, I assume, for example, that
if you accidentally backup/restore the filesystem in a way that
doesn't preserve hard-links, you might be surprised by the resulting
expansion.

Also, I assume that you have to be careful not to accidentally modify
files in the working directory without breaking hard-links (and make
sure that the build process doesn't either), or you'll end up with
modifications in all the working dirs that are hard-linked to the
current one.  If that were to happen could it be fixed via "bzr
revert" in all the affected trees?

Also, does a "bzr pull SOURCE" only pull from the .bzr directory in
SOURCE?  i.e. only the committed changes?

Thanks again
-- 
Rob Browning
rlb @defaultvalue.org and @debian.org; previously @cs.utexas.edu
GPG starting 2002-11-03 = 14DD 432F AE39 534D B592  F9A0 25C8 D377 8C7E 73A4