launchpad help|
Size: 5271
Comment:
|
Size: 5218
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| Line 4: | Line 3: |
| The combination of Bazaar branch hosting and teams 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 (with a centralized hosting of a branch that many people commit to). | The combination of Bazaar branch hosting and teams 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. |
| Line 8: | Line 9: |
| It is possible for multiple people in a team each to "{{{bzr push}}}" their branches to the same location in the team space (for example, ~team/gnuhello/newfeature). Bazaar will make sure that each push doesn't overwrite the work that is already there - it must extend that work. However, this is not usually considered the optimal arrangement because each "push" can change the history of the branch in a dramatic way. | It is possible for multiple people in a team each to "{{{bzr push}}}" their branches to the same location in the team space. For example, ~team/gnuhello/newfeature. |
| Line 10: | Line 11: |
| In order to get a more SVN-like experience, we usually recommend that people use Bazaar '''checkouts''' of a team branch. A checkout is essentially JUST the working code tree, without all the branch history, because the branch history stays on the central server. When using Bazaar in this fashion it behaves very similarly to SVN. You cannot commit locally, because the knowledge of your branch history is over 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. | Bazaar will make sure that each push doesn't overwrite the work that is already there. Instead, it must extend that work. However, this is not usually the most optimal arrangement because each "push" can change the history of the branch in a dramatic way. To get a more SVN-like experience, we usually recommend that people use Bazaar '''checkouts''' of a team branch. A checkout is essentially JUST the working code tree, without all the branch history, because the branch history stays on the central server. 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. |
| Line 14: | Line 19: |
| In order to create a team branch, you just push a branch into a team space. For example, if you are still in the {{{gnuhello}}} branch you created during the earlier example, and you are a member of the {{{test-team}}} team, then you could create a shared branch of GNU Hello called "newfeature" using the following command: | To create a team branch, simply push a branch into a team space. For example, if you are still in the {{{gnuhello}}} branch you created during the earlier example, and you are a member of the {{{test-team}}} team, then you could create a shared branch of GNU Hello called "newfeature" using the following command: |
| Line 29: | Line 34: |
| It is extremely easy to administer the set of people who can commit to a branch like this, because it is just the set of members of the team. So it's trivial to create a team to collaborate on a feature - just make a team with the people you want to be able to commit to the mainline branch for the feature, and push the initial branch to that team space, then tell everyone to commit there! | Launchpad makes it extremely easy to administer the set of people who can commit to a branch like this, because they are simply the members of the team. |
| Line 31: | Line 36: |
| Team branches are a very popular way for the Ubuntu teams to collaborate. For example, you can setup teams around a single package or set of packages, and work on shared branches that have the latest version of the relevant code in them. | This means that it is trivial to create a team to collaborate on a feature. Create a new Launchpad team, with the people that you want to be able to commit to the feature's mainline branch. Push the initial branch to that team space. Then, tell everyone to commit there! |
| Line 33: | Line 38: |
| The best example of all of that is the Ubuntu Core Development Team, which has branches for many projects which are shared and to which any team member can commit: | Team branches are a very popular way for the Ubuntu teams to collaborate. For example, you can set up teams around a single package or set of packages, and work on shared branches that contain the latest version of the relevant code. The best example is the Ubuntu Core Development Team. It has branches for many projects that are shared and to which any team member can commit: |
| Line 41: | Line 48: |
| Notice how this is being used to keep track of packages that the team happens to maintain in both Debian and Ubuntu. Shared branches can be used for cross-project collaboration in a very efficient way, with branches for specific projects and shared branches for work that is common to both of them. | Notice how this is being used to keep track of packages that the team maintains both in Debian and Ubuntu. Shared branches can be used for cross-project collaboration in a very efficient way, with branches for specific projects and shared branches for work that is common to both of them. |
| Line 45: | Line 52: |
| It is of course possible to get the best of both worlds, combining branches and checkouts. In the above example, a member of the team might have a checkout of the mainline branch to which they can commit, but then separately make their own branch locally which allows them to commit locally. They would develop on their own local branch (perhaps pushing that up to the server in their own space rather than the team space). This gives them full revision control in their own branch. When they are ready to commit their work to the shared team mainline branch for the feature, they can simply make sure their checkout of that branch is up to date, then merge from their local branch, and commit to the central server. | It is of course possible to get the best of both worlds, by combining branches and checkouts. In the above example, a member of the team might have a checkout of the mainline branch to which they can commit, but then separately make their own branch locally which allows them to commit locally. They would develop on their own local branch, perhaps pushing that up to the server in their own space rather than the team space. This gives them full revision control in their own branch. When they are ready to commit their work to the shared team mainline branch for the feature, they simply make sure their checkout of that branch is up to date, then merge from their local branch, and commit to the central server. |
| Line 49: | Line 60: |
| The freedom to create branches is wonderful for encouraging participation. With all those branches out there, it's good to tell people which ones are most relevant to them. Pick good names for your branches! Also, use the branch status (New, Experimental, Mature, Obsolete etc) to provide a hint to potential collaborators or testers about the maturity of your code. | The freedom to create branches is wonderful for encouraging participation. With all those branches out there, it's good to tell people which ones are most relevant to them. Pick good names for your branches! Also, use the branch status - New, Experimental, Mature, Obsolete, etc - to provide a hint to potential collaborators or testers about the maturity of your code. |
| Line 51: | Line 62: |
| But perhaps the most useful thing you can do is to link your branches to the descriptions of the work that they are implementing. For example, if you have a bug that you are fixing, link the branch to that bug report! And if it's a new feature, then have a record of that feature in Launchpad (we call it a Blueprint) and link the branch to that. That's the [:ReviewersGuide/BugBranchLinking:next stop] in our review of Launchpad. | One of the most useful things you can do is to link your branches to a description of the work they implement. For example, if your branch fixes a bug, link the branch to the bug report! And if it's a new feature, track that feature in Launchpad (we call it a Blueprint) and link the branch to that. That's the [:ReviewersGuide/BugBranchLinking:next stop] in our review of Launchpad. |
Team branches
The combination of Bazaar branch hosting and teams 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.
Bazaar checkouts
It is possible for multiple people in a team each to "bzr push" their branches to the same location in the team space. For example, ~team/gnuhello/newfeature.
Bazaar will make sure that each push doesn't overwrite the work that is already there. Instead, it must extend that work. However, this is not usually the most optimal arrangement because each "push" can change the history of the branch in a dramatic way.
To get a more SVN-like experience, we usually recommend that people use Bazaar checkouts of a team branch. A checkout is essentially JUST the working code tree, without all the branch history, because the branch history stays on the central server.
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.
Setting up a team branch
To create a team branch, simply push a branch into a team space. For example, if you are still in the gnuhello branch you created during the earlier example, and you are a member of the test-team team, then you could create a shared branch of GNU Hello called "newfeature" using the following command:
% bzr push sftp://<me>@bazaar.launchpad.net/~test-team/gnuhello/newfeature Created new branch.
Now, it is possible for anybody else to branch from that branch. It is also possible for anyone in the test-team to push an updated version of that branch to the same location. But the preferred approach, in general, is to encourage other team members to use a checkout of the branch:
% bzr checkout sftp://<me>@bazaar.launchpad.net/~test-team/gnuhello/newfeature
Now, whenever they commit, Bazaar will first make sure they are up to date. If not, they can get up to date with bzr update and then commit.
Launchpad makes it extremely easy to administer the set of people who can commit to a branch like this, because they are simply the members of the team.
This means that it is trivial to create a team to collaborate on a feature. Create a new Launchpad team, with the people that you want to be able to commit to the feature's mainline branch. Push the initial branch to that team space. Then, tell everyone to commit there!
Team branches are a very popular way for the Ubuntu teams to collaborate. For example, you can set up teams around a single package or set of packages, and work on shared branches that contain the latest version of the relevant code.
The best example is the Ubuntu Core Development Team. It has branches for many projects that are shared and to which any team member can commit:
Here's a snippet from that page showing some of their branches:
attachment:ubuntucoredevbranches.png
Notice how this is being used to keep track of packages that the team maintains both in Debian and Ubuntu. Shared branches can be used for cross-project collaboration in a very efficient way, with branches for specific projects and shared branches for work that is common to both of them.
Combining branches and checkouts
It is of course possible to get the best of both worlds, by combining branches and checkouts.
In the above example, a member of the team might have a checkout of the mainline branch to which they can commit, but then separately make their own branch locally which allows them to commit locally.
They would develop on their own local branch, perhaps pushing that up to the server in their own space rather than the team space. This gives them full revision control in their own branch. When they are ready to commit their work to the shared team mainline branch for the feature, they simply make sure their checkout of that branch is up to date, then merge from their local branch, and commit to the central server.
Branch statuses and links
The freedom to create branches is wonderful for encouraging participation. With all those branches out there, it's good to tell people which ones are most relevant to them. Pick good names for your branches! Also, use the branch status - New, Experimental, Mature, Obsolete, etc - to provide a hint to potential collaborators or testers about the maturity of your code.
One of the most useful things you can do is to link your branches to a description of the work they implement.
For example, if your branch fixes a bug, link the branch to the bug report! And if it's a new feature, track that feature in Launchpad (we call it a Blueprint) and link the branch to that.
That's the [:ReviewersGuide/BugBranchLinking:next stop] in our review of Launchpad.
