bzr overview questions.

[Martin Pool]

On 06/09/05, Rob Browning <rlb at defaultvalue.org> wrote:
> So does bzr hard link by default in this situation, or do you need cp
> -al for that?

At the moment you must use cp -al manually.  As discussed in another
thread today, we should perhaps change that to be the built-in
behaviour, on platforms where symlinks are known to work safely (not
macos).

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

bzr's designed to not normally require access to any other archives,
which is how we can dispense with the archive naming and registration
problems that have impeded Arch usability.  So all the history from
the other branch will normally be copied in to your branch, which
requires some attention to compact storage.

That said if you know the other archive will always be around there
may be an efficiency option to not copy, but rather just refer to it.

If an archive moves or goes away and people then you need to somehow
advertise the new updated URL, e.g. by changing the project's web page
or sending email to people using at that branch.

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

That is true.  Initial results with the weave storage code show it can
be very compact.

(The problem is a bit like the way a naive checkout of the root of a
svn repository with lots of CoW branches can generate hundreds of
gigabytes of data.)

The point of using directories as branches is not that it's the total
and perfect solution, but rather that it's a good simple model, and we
can add performance features later.

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

Yes, that would fix it.  We should have some kind of command to break
those links.

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

Yes.

-- 
Martin