Colocated branches transparent for users

Asked by Radoslaw Grzanka

Hello,
  I have one central repository for my (large) project. There is circa 20 developers that push and pull changes. Let's say that this repository is located at:
   bzr://0.0.0.0/trunk

I'd like to introduce colocated branches (in the spirit of GIT) for those developers that would like to use it but I'd like to retain central repo behaviour. For example, users still can work like usual doing:

> bzr merge --pull bzr://0.0.0.0/trunk
worky...worky
> bzr commit -m "new feature"
> bzr push bzr://0.0.0.0/trunk

but for those developers that would like to use colocated branches they could do this:

> bzr colo-fetch bzr://0.0.0.0/trunk project
> cd project
> bzr colo-branch new_feature
worky worky
> bzr commit -m "proposed new feature"
> bzr push colo:bzr://0.0.0.0/trunk:new_feature

and later me or tester can integrate this change to trunk and then this feature is visible for old-mind users.

Is this possible? I tried to set this up but each time I stumble upon some problem/error or total repository breakdown.

Thanks in advance,
  Radek.

Question information

Language:
English Edit question
Status:
Solved
For:
Bazaar Edit question
Assignee:
No assignee Edit question
Solved by:
Radoslaw Grzanka
Solved:
Last query:
Last reply:
Revision history for this message
Martin Packman (gz) said :
#1

It may be possible, but is likely to be more accident prone. Mixing bound branches and unbound feature branches in the same location is asking for people to make mistakes over where a commit ends up going.

For developers that want to work in feature branches but not have lots of working trees lying around, a more explicit layout using a shared repo without trees may acceptable. If your central server is quick, developers could still just have one copy locally, though it's clearer if they have at least separate local trunk and feature trees in a shared repo.

    # get copy of trunk
    $ bzr checkout bzr://central/trunk project
    $ cd project

    # start working on new feature
    $ bzr switch -b bzr://central/name_for_new_feature
    # make changes
    $ bzr commit

    # land feature
    $ bzr switch bzr://central/trunk
    $ bzr merge bzr://central/name_for_new_feature
    $ bzr commit

Using local branches for features is easier, and they can be manually pushed to central for collaboration as needed.

Compare the centralised and distributed workflows in the user guide for more:

<http://doc.bazaar.canonical.com/latest/en/user-guide/index.html>

Revision history for this message
Radoslaw Grzanka (radoslawg) said :
#2

Thanks Martin for answer.

I made it work "my way" (tm) by manually doing some colocated branches setup step. Namely

Server side:

$ cd /var/lib/bzr/trunk/.bzr
$ bzr init-repo branches

Client side

$ bzr colo-fetch bzr://0.0.0.0/trunk project

# This creates project directory with "origin/trunk" branch - which is very handy

$ bzr colo-branch new_feature
worky..worky
$ bzr push colo:bzr://0.0.0.0/trunk:new_feature # now it works..

From here tester can take over pulling from central repo.