tags:

views:

101

answers:

3

I am wondering what different between bzr init-repo Repo and bzr init-repo Repo --no-trees. I've tried them and cannot seems to see what is the different.

For both, I cannot add file directly into the repo (I have to create branch first). They seems to behave exactly the same to me.

Would anyone explain me what are the differences?

EDIT: Thank you all of you who answer. However, I still did not quite understand the practical differences after I read your answers.

I did some more experiments and found that with/without a tree, I can create branch in side the repository (bzr init). But only with the one with trees, I can add a file and commit. The one without trees, I can only pull from some where else.

In other word, the one without tree are those almost-read-only ('Almost' because you can still pull new branch from somewhere else). What is the use of this? Is performance is the only reason?

Thanks in advance.

A: 

From the docs

If the --no-trees option is used then the branches in the repository will not have working trees by default.

And a working tree is the result from a bzr checkout

Basically... if you want to work with the repository and want to be able to commit the changes you're making, you'll want a working tree ;)

WoLpH
+1  A: 

The main unit in bzr is a branch (created with bzr init).

Shared repository (created with bzr init-repo) is the additional thing to store the history of several branches in the one place and share this history between all branches within this repository.

Flag --no-trees used for the case when you don't need a working trees for your branches. E.g. on the central server. So, branches without working trees takes very little space on the disk.

For local work on branches you definitely need working trees, so you need to create shared repository with trees.

bialix
+2  A: 

To explain a little more clearly, the -no-trees option means that a working tree is not kept for any of the branches stored within the repository.

What does that mean?

1) The repository doesn't hold your source files. Don't believe me? Go cd into a branch inside a no-trees repository and tell me what a "ls" gets you. Nothing.

Now, what is actually stored there is the HISTORY of the files, so that a file can be reconstructed from that history.

2) You can't work inside a no-trees repository as there is no working tree. You discovered this yourself - you can't commit. Why not? Because the files aren't there. Only their history is.

So, what good are no-trees repositories? Like was stated, they're good for a central server. If you and Bob are working on a project, and you're not always going to be able to push/pull from each other's personal machines, or you work in a company that wants a place for the latest clean "trunk" then a shared server with a no-trees repository is your answer.

Here's how it works. You create the repository on the shared server with the no-trees option and then import your "trunk" into the repository.

You then pull down the latest copy of the "trunk" with something like bzr branch bzr+ssh://mysharedserver/myrepo/trunk trunk_mirror

That gets you a "mirror" copy of the trunk. You then create branches off of that mirror copy for your new features, bugfixes, etc, committing all you want.

Now you're going out of town and Bob needs your code. Since it's ready, you merge it into the trunk mirror:

cd trunk_mirror bzr merge ../my_really_cool_feature_branch bzr commit "added my cool feature to trunk" bzr push

The last step pushes your changes to the mirrored trunk up to the shared repository where Bob will be able to do a "pull" and get the latest copy of the trunk.

Wade Williams
This answer really clear thing up. Thanks alot.
NawaMan
sounds like `--bare` in `git init`
hasen j