Bazaar

nested style: why use them and how to merge?

Asked by Didier Roche-Tolomelli

Hi everyone.
Following the Bazaar User Guide, I read the "10.2.2 Nested Style (project/branch/sub-branch/)" paragraph.

As I can understand that this is better for visualizing branches "interweaving", I do not see any other avantage on it.

For instance from your stanza:
project/ # The overall repository, *and* the project's mainline branch
 + joe/ # Developer Joe's primary branch of development
 | +- feature1/ # Developer Joe's feature1 development branch
 | | +- broken/ # A staging branch for Joe to develop feature1
 | +- feature2/ # Joe's feature2 development branch
 | ...
 + barry/ # Barry's development branch
 | ...

This is the local view (which is also the hierarchical on the fs if we use nested tree). But after having done "init-repo --no-tree", we have the created branches and then, to make this logicial statement:
  - from project/joe: bzr push ..
  - from project/joe/feature1: bzr push ..
  - from project/joe/feature1/broken: bzr push ..
  - from project/joe/feature2: bzr push ..
  - from project/barry: bzr push ..
  - and so on.

So, this is why I do not see the difference beetween this way and the following one.
On the FS:
- Project/
  + joe/
  + feature1/
  + broken/
  + feature2/
  + barry/

And then, to have the same logical interweaving:
- from project/joe: bzr push ..
- from project/feature1: bzr push ../joe
- from project/borken: bzr push ../feature1
- from project/feature2: bzr push ../joe
- from project/barry: bzr push ..

The logical view is the same, even if the FS projection is different (and can be on different hosts).

Furthermore (stop me if I am wrong), with nested style with no-tree, We have to checkout each branches (for instance, mine in project/joe) from the initial (main) repository to work locally on our hosts. Is it correct? (and this is the only way also to be able to achieve some merge).

So, from what I understant:
  - nested style is to have a physical view of a logical structure
  - all branches are located on a main repository with no associated tree (so that we can view the full structure, otherwise, this approach lost is advantage to be able to view physically each branch). And we checkout locally the branches we want to work on.

Am I correct (sorry for this long question)?

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
John A Meinel
Solved:
Last query:
Last reply:
Revision history for this message
Best John A Meinel (jameinel) said : 		#1

There is no specific advantage to any repository layout. It is strictly about how you want to convey your structure.

You are completely correct that "cd project/joe/feature1, bzr push .." is the same as "cd project/feature1; bzr push ../joe".

I personally use a different structure (without nesting) of the form:
project/
  1.4-dev/
    feature1
    bugfix_23424
  1.5-dev/
    bugfix-2242

Which is more of the form (10.2.4)
http://doc.bazaar-vcs.org/bzr.dev/en/user-guide/index.html#sorted-by-date-release-etc-2006-06-2006-07-0-8-0-9

However, I'm the only developer in this repository, but I create far more branches than I think most people do.

So a lot of the recommended layout depends on how the repository is going to be used. You can certainly use a flat structure. That doesn't work well for *me* because when you have ~200ish branches, it becomes difficult to find what you are looking for. If you have 5 developers, and they each start creating lots of feature branches, a flat namespace ends up very cluttered. And you are likely to end up with branches named something like "joe-feature1", "barry-bugfix10". Which is pretty much the same as "joe/feature1" and "barry/bugfix10". Except doing "ls" at the top level shows different amounts of information.

For the official bzr repository, we use a flat namespace, because it only includes officially released branches so we have:
http://bazaar-vcs.org/bzr/ # repo root
    bzr.dev # "trunk"
    bzr.0.15
    bzr.1.1
    bzr.1.2
    ...

In general, to do work you will want to do a checkout to your local workstation. You need a workingtree to do merging. This is independent of the repository layout.

Revision history for this message
Didier Roche-Tolomelli (didrocks) said : 		#2

Perfectly clear :)
I just wanted to be confirmed what I thought.

Ok, this should mean than doing "bzr branch ..." in a shared repository (so, with a working tree) is performing automatically a checkout.

So, this kind of workflow (with nested branches in a repository and checkouts on developper workstation) is more a centralized view with which you can work disconnected as every "structures" information (not history) is on a centralized server?

Revision history for this message
John A Meinel (jameinel) said : 		#3

a shared repository does not inherently create working trees. (it depends on bzr init-repo --trees or --no-trees). I think there are a few bits of confusion left.

In general, if you have a shared repository on the server and checkouts, it is a "centralized view". However, if you also create a local shared repository, and use heavyweight checkouts (the default), you are then able to "break away" from the central repository at any time, because you've also copied the history to your local machine. (A heavyweight checkout copies the data and has a local repository (may or may not be shared), branch, and working tree. A lighweight checkout only has the local working tree.)

Revision history for this message
Didier Roche-Tolomelli (didrocks) said : 		#4

Thanks John A Meinel, that solved my question.