bzr overview questions.

[Rob Browning]

Martin Pool <martinpool at gmail.com> writes:

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

Understood, though it may take a bit of adjustment to get used to the
idea that keeping 50 branches of a project requires 50 complete
working directories, rather than some optimized repository from which
you can pull (at some expense) an individual branch if needed.

It might also be good to mention the issues with hard-links more
explicitly in the FAQ (where cp -al is suggested), or elsewhere.  In
particular, mention that there are various ways that the hard-linked
trees can be indirectly damaged, including modifications by build
commands that alter revision controlled files, but then note that it
is easy to detect and repair this damage via "bzr status" and "bzr
revert".

Of course, for longer-term storage, I suppose you can archive all of a
project's branch directories with tar and then just extract what you
need when appropriate:

  tar xzpSf project-archive.tgz ./project-archive/release/2.1.2

Though you would still have to have enough space to extract the whole
archive to easily rearrange or update it, and I'm not sure how much
space you would be likely to save since the contents of .bzr are
already compressed.

Again though, I do like the simplicity.  I'm just trying to make sure
I understand how bzr's model affects common practices.

Thanks
-- 
Rob Browning