Diff for "Code/TeamBranches"

Not logged in - Log In / Register

Differences between revisions 1 and 5 (spanning 4 versions)
Revision 1 as of 2008-09-09 14:13:30
Size: 3196
Editor: 92-237-59-186
Comment: work in progress
Revision 5 as of 2008-10-10 15:00:36
Size: 6353
Editor: 92-237-59-186
Comment: Publication
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
'''DRAFT: this page is a work in progress. Please [[Feedback|seek further help]] or check the [[TitleIndex|wiki index]] for a complete page on this topic.''' ## page was renamed from Code/TeamBranches/Draft
~-[[FrontPage|Launchpad Help]] > [[Code]] > Team branches -~
Line 11: Line 12:
However, Bazaar is flexible enough that you can choose your own workflow.
Line 15: Line 18:
Once Launchpad has registered your branch, you'll see the new branch's overview page. There, you can find the Bazaar command you need to use to push code to your new team branch. Next, you need to make the first push up to Launchpad. Again, this works just the same as with a personal branch.

= Choosing a workflow =

When you're working with a team branch, you can choose one of three workflows:

 * '''Centralised:''' also called ''lock-step'', this is how Subversion and CVS work. Everyone makes commits direct to the central branch.
 * '''Centralised with local commits:''' similar to centralised, except that when developers are making a series of changes they use "commit --local", or unbind their checkout, then commit their work to the shared main line when it is complete.
 * '''Decentralised with shared main line:''' each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the main line when it is ready.

If you're not sure which workflow would best suit your team, there's [[more about Bazaar workflows]] in the Bazaar documentation. However, you may find that you need to experiment before you settle on one that works for your team.

== Centralised (or lock-step) ==

A team using the centralised workflow might work something like this:

 * Team members Alf, Bharat and Momoe each check out the team branch.
 * Alf adds a new feature and commits his work straight back to the team branch on Launchpad.
 * Momoe starts work on a new feature and attempts to commit back to the team branch. Bazaar tells Momoe that her local checkout is out of date, thanks to Alf's update. So, Momoe uses ''bzr update'' to pull the latest version of the working tree from Launchpad before committing her changes back up to Launchpad.
 * Bharat wants to work on an experimental idea, so creates his own personal branch of the team branch, enabling him to work separately but retaining the ability to merge back into the team branch later.
 
To make the initial check-out of a team branch, open a terminal and type:

{{{
 $ bzr checkout lp:team-name/project-name/branch-name
}}}
 
Bazaar will now download just enough information to enable you to work on the code: i.e. the branch's working tree without its revision history.

When you're ready to send your work back to the branch, you commit in the usual way:

{{{
 $ bzr commit -m "Enter a commit message here"
}}}

The difference here is that Bazaar pushes your commit directly back up to Launchpad, rather than making the commit to a local branch on your computer.

As we saw in the example above, it's entirely possible that someone else may have made a commit to the team branch during the time between your check-out and when you're ready to make your commit. If that's the case, Bazaar will tell you and you'll need to pull down the latest version by typing:

{{{
 $ bzr update
}}}

During the update, Bazaar will merge the latest version of the branch into your local working tree. Although Bazaar has excellent support for merging, you may find some conflicts. See the section on [[http://doc.bazaar-vcs.org/latest/en/user-guide/index.html#resolving-conflicts|resolving conflicts]] in the Bazaar user guide.

=== Pros and cons ===

''Seek input''.
Line 18: Line 68:
== Centralised with local commits ==
Line 19: Line 70:
= Instructional text = This works just like the ''centralised'' model except that each member of the team has the option of making local commits as well as committing directly to the team branch.
Line 21: Line 72:
Where appropriate, use step by step instructions: To make a local commit, rather than commit to the team branch, use:
Line 23: Line 74:
'''Step 1:''' Give concise and unambiguous instructions. {{{
 $ bzr commit -m "Commit message" --local
}}}
Line 25: Line 78:
'''Step 2:''' Try not to state the obvious, unless you're writing for a novice user. Then commit as normal when you're ready to send your changes back to the team branch.
Line 27: Line 80:
{i} '''Note:''' Highlight important information with a note. === Pros and cons ===
Line 29: Line 82:
'''Step 3:''' Use a well cropped screen shot if it will help orient the reader. Don't let the screen shot replace instructional text: not everyone can see your screen shot. Don't worry about borders or annotation for small, cropped screen shots such as this. '''Advantages:'''
Line 31: Line 84:
{{attachment:screen-shot.png}}  * Allows for off-line development.
 * Less chance of a bad commit affecting everyone else's work.
 
'''Disadvantages:'''
Line 33: Line 89:
{i} '''Warning:''' If you're about to tell the reader to delete or otherwise change something that would be hard to restore, warn them. ''Seek input''
Line 35: Line 91:
== Decentralised with shared main line ==
Line 36: Line 93:
== Full screen shots == Using this workflow, each team member developer has their own branch or branches, as well as commit rights to the team branch. They work in their personal branch, then merge it into the mainline when it is ready.
Line 38: Line 95:
||<tablestyle="float:right; font-size: 0.8em; width:30%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;">{{attachment:proj-announce.png}}||
||<style="text-align: center;">'''Describe the screen shot here'''||
So, rather than checking out the team branch, you create your own local branch:
Line 41: Line 97:
Some screen shots will be better placed to the right of your text. As they're not placed directly below the text that they support, use a border and short description. {{{
 $ bzr branch lp:team-name/project-name/branch-name
}}}
Line 43: Line 101:
Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Aliquam sagittis. Aliquam eros dui, scelerisque id, consequat in, accumsan vitae, pede. Suspendisse neque ligula, scelerisque ac, mattis ut, aliquam quis, odio. Then, you work as normal on your local branch - making commits to it whenever you need to - and only merge with team branch when you have something that you're happy with.
Line 45: Line 103:
Proin nunc nisi, fringilla ac, congue ac, luctus eu, lacus. Maecenas ac purus. Cras felis metus, ultricies non, euismod ac, accumsan eleifend, leo. Quisque imperdiet tempus tellus. ''Seek input on command to use. Presumably bzr merge lp:team-name/project-name/branch-name''
Line 47: Line 105:
Ut euismod, diam nec adipiscing interdum, tortor orci fringilla nisi, vel blandit erat magna at nisi. Fusce hendrerit odio non metus. Mauris nisl massa, dapibus id, feugiat quis, blandit a, quam. Integer tincidunt feugiat nunc. Curabitur iaculis egestas elit. Nam imperdiet suscipit odio. === Pros and cons ===

'''Advantages:'''

 * Easier organization of work - separate changes can be developed in their own branches.
 * Developers can merge one another's personal branches when working on something together.
 
''Seek input''

= Next step =

If you're using the ''decentralised with shared main line'' workflow, or you need to merge branches for any other reasons, Launchpad's code review gives you a public and easy way to review merge proposals. Let's look at [[Code/Review|code review]] now.

||<tablestyle="width: 100%;"> ~-[[Code/UploadingABranch|< Uploading a branch to Launchpad]] -~ ||<style="text-align: right;"> ~- [[Code/Review|Code review >]] -~ ||

Launchpad Help > Code > Team branches

Overview

The combination of Bazaar branch hosting and Launchpad's teams infrastructure gives you a very powerful capability to collaborate on code. Essentially, you can push a branch into a shared space and anyone on that team can then commit to the branch.

This means that you can use Bazaar in the same way that you would use something like SVN, i.e. centrally hosting a branch that many people commit to. You have the added benefit, though, that anyone outside the team can always create their own personal branch of your team branch and, if they choose, upload it back to Launchpad.

However, Bazaar is flexible enough that you can choose your own workflow.

Creating your team branch

Registering a team branch works the same way as registering a personal branch: visit your team's code overview page, click Register a branch, then follow the instructions.

Next, you need to make the first push up to Launchpad. Again, this works just the same as with a personal branch.

Choosing a workflow

When you're working with a team branch, you can choose one of three workflows:

  • Centralised: also called lock-step, this is how Subversion and CVS work. Everyone makes commits direct to the central branch.

  • Centralised with local commits: similar to centralised, except that when developers are making a series of changes they use "commit --local", or unbind their checkout, then commit their work to the shared main line when it is complete.

  • Decentralised with shared main line: each developer has their own branch or branches, plus commit rights to the main branch. They do their work in their personal branch, then merge it into the main line when it is ready.

If you're not sure which workflow would best suit your team, there's more about Bazaar workflows in the Bazaar documentation. However, you may find that you need to experiment before you settle on one that works for your team.

Centralised (or lock-step)

A team using the centralised workflow might work something like this:

  • Team members Alf, Bharat and Momoe each check out the team branch.
  • Alf adds a new feature and commits his work straight back to the team branch on Launchpad.
  • Momoe starts work on a new feature and attempts to commit back to the team branch. Bazaar tells Momoe that her local checkout is out of date, thanks to Alf's update. So, Momoe uses bzr update to pull the latest version of the working tree from Launchpad before committing her changes back up to Launchpad.

  • Bharat wants to work on an experimental idea, so creates his own personal branch of the team branch, enabling him to work separately but retaining the ability to merge back into the team branch later.

To make the initial check-out of a team branch, open a terminal and type:

 $ bzr checkout lp:team-name/project-name/branch-name

Bazaar will now download just enough information to enable you to work on the code: i.e. the branch's working tree without its revision history.

When you're ready to send your work back to the branch, you commit in the usual way:

 $ bzr commit -m "Enter a commit message here"

The difference here is that Bazaar pushes your commit directly back up to Launchpad, rather than making the commit to a local branch on your computer.

As we saw in the example above, it's entirely possible that someone else may have made a commit to the team branch during the time between your check-out and when you're ready to make your commit. If that's the case, Bazaar will tell you and you'll need to pull down the latest version by typing:

 $ bzr update

During the update, Bazaar will merge the latest version of the branch into your local working tree. Although Bazaar has excellent support for merging, you may find some conflicts. See the section on resolving conflicts in the Bazaar user guide.

Pros and cons

Seek input.

Centralised with local commits

This works just like the centralised model except that each member of the team has the option of making local commits as well as committing directly to the team branch.

To make a local commit, rather than commit to the team branch, use:

 $ bzr commit -m "Commit message" --local

Then commit as normal when you're ready to send your changes back to the team branch.

Pros and cons

Advantages:

  • Allows for off-line development.
  • Less chance of a bad commit affecting everyone else's work.

Disadvantages:

Seek input

Decentralised with shared main line

Using this workflow, each team member developer has their own branch or branches, as well as commit rights to the team branch. They work in their personal branch, then merge it into the mainline when it is ready.

So, rather than checking out the team branch, you create your own local branch:

 $ bzr branch lp:team-name/project-name/branch-name

Then, you work as normal on your local branch - making commits to it whenever you need to - and only merge with team branch when you have something that you're happy with.

Seek input on command to use. Presumably bzr merge lp:team-name/project-name/branch-name

Pros and cons

Advantages:

  • Easier organization of work - separate changes can be developed in their own branches.
  • Developers can merge one another's personal branches when working on something together.

Seek input

Next step

If you're using the decentralised with shared main line workflow, or you need to merge branches for any other reasons, Launchpad's code review gives you a public and easy way to review merge proposals. Let's look at code review now.

< Uploading a branch to Launchpad

Code review >

Code/TeamBranches (last edited 2012-04-05 00:24:42 by wgrant)