What do I call a working tree that stores its revisions in a shared repository?

Talden talden at gmail.com
Sun Mar 30 23:21:25 BST 2008


On Mon, Mar 31, 2008 at 10:56 AM, Paul Moore <p.f.moore at gmail.com> wrote:
> This sounds like a dumb question, but it's one that I found *really*
>  hard when I was putting together my performance figures. The
>  performance of branching to a standalone tree is *far* worse than for
>  branching to a ... well, a working tree that uses a shared repository.
>  So it seems to me that the far more common physical object probably
>  ought to be a working tree using a shared repository, both for
>  performance and disk usage reasons - but there's no simple name for
>  it!
>
>  I can't even think of a good name to suggest, because it's not a
>  property of the directory itself, but more of where it's located. The
>  best I can think of is a "dependent tree" or something - to reflect
>  the fact that while you can rename or move a standalone tree as you
>  like, but a "dependent tree" is tied to its location in relation to
>  the shared repository.
>
>  Can anyone come up with something better?
>
>  Oh, and while I'm on the subject, that's a significant problem with
>  shared repositories in some situations, the fact that you *can't*
>  treat them as independent objects (zip them up, move them around,
>  email them, etc). It's probably the main reason why, in spite of the
>  space penalties, I'd much rather use standalone trees - and why I am
>  so discouraged by the huge performance penalties they incur on large
>  repositories. So although I can see the benefits of shared
>  repositories, I don't like feeling that they are necessary, the way I
>  do at the moment for large projects.
>
>  Paul.
>
>  PS Given that it's possible to copy standalone trees *far* faster than
>  "bzr branch"-ing them, is there any reason not to create a branch via
>  copying instead of branching?

When you want to move them, branch them.  That way I assume you'd only
be wearing the cost of the branching in the exceptional cases. Unless
of course you expect to be copying and moving trees around all the
time.

Naturally the creation of 'stand-alone' branches has to be more
expensive - there's no way to avoid the fact that there's extra IO.

It might be nice though, and given my limited knowledge of Bazaar it
might already be possible, to provide a command for switching between
standalone and shared.

EG the workflow could be

> mv ~/standalone_branch_x ~/shared_repo/x
# eliminate repository revs already in the shared repo and copy those
that aren't, cleaning out the repo at the end.
> bzr convert x --shared

and likewise

# Copy shared revs that are part of the branch ancestry into a standalone repo.
> bzr convert x --standalone
> mv ~/shared_repo/x ~/standalone_branch_x

This would avoid the costs of rebuilding the working-tree and it's
merely copying to/from a shared repo and removing/adding repository
content in the standalone branch.

--
Talden



More information about the bazaar mailing list