Diff for "Code/TeamBranches"

Not logged in - Log In / Register

Differences between revisions 2 and 3
Revision 2 as of 2008-09-10 14:00:02
Size: 6831
Comment: work in progress
Revision 3 as of 2008-09-10 15:30:28
Size: 6232
Comment:
Deletions are marked like this. Additions are marked like this.
Line 38: Line 38:
To make the initial check-out of a team branch, you need to open a terminal and type: To make the initial check-out of a team branch, open a terminal and type:
Line 60: Line 60:
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. 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.
Line 62: Line 62:
'''Advantages:''' === Pros and cons ===

''Seek input''.
Line 65: Line 67:
With a centralised workflow, each developer checks-out the team branch and makes their commits straight back to then commits their work back == Centralised with local commits ==
Line 67: Line 69:
A checkout is essentially just the working code tree, without all the branch history, because the branch history stays on the central server. 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 69: Line 71:
When using Bazaar in this fashion it behaves very similarly to SVN. You cannot commit locally, because the knowledge of your branch history is on the remote server. But it does mean that you use less space locally, because you don't need to store all of that history locally too. To make a local commit, rather than commit to the team branch, use:
Line 71: Line 73:
= Getting started with an existing team branch = {{{
 $ bzr commit -m "Commit message" --local
}}}
Line 73: Line 77:
If you're new to a team and want to start Then commit as normal when you're ready to send your changes back to the team branch.
Line 75: Line 79:
=== Pros and cons ===
Line 76: Line 81:
== Centralised (lock-step) == '''Advantages:'''
Line 78: Line 83:
 * Allows for off-line development.
 * Less chance of a bad commit affecting everyone else's work.
 
'''Disadvantages:'''
Line 79: Line 88:
''Seek input''
Line 80: Line 90:
== Decentralised with shared main line ==
Line 81: Line 92:
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 82: Line 94:
So, rather than checking out the team branch, you create your own local branch:
Line 83: Line 96:
{{{
 $ bzr branch lp:team-name/project-name/branch-name
}}}
Line 84: Line 100:
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 85: Line 102:
''Seek input on command to use. Presumably bzr merge lp:team-name/project-name/branch-name''
Line 86: Line 104:
=== Pros and cons ===
Line 87: Line 106:
'''Advantages:'''
Line 88: Line 108:
= Instructional text =  * 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''
Line 90: Line 113:
Where appropriate, use step by step instructions: = Next step =
Line 92: Line 115:
'''Step 1:''' Give concise and unambiguous instructions.

'''Step 2:''' Try not to state the obvious, unless you're writing for a novice user.

{i} '''Note:''' Highlight important information with a note.

'''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.

{{attachment:screen-shot.png}}

{i} '''Warning:''' If you're about to tell the reader to delete or otherwise change something that would be hard to restore, warn them.


== Full screen shots ==

||<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'''||

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.

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.

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.

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.
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.

DRAFT: this page is a work in progress. Please seek further help or check the wiki index for a complete page on this topic.

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.

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