← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/en/user-guide/partner_intro.txt

  • Committer: Robert Collins
  • Date: 2005-10-19 10:11:57 UTC
  • mfrom: (1185.16.78)
  • mto: This revision was merged to the branch mainline in revision 1470.
  • Revision ID: robertc@robertcollins.net-20051019101157-17438d311e746b4f
merge from upstream

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/en/user-guide/partner_intro.txt
1
 
Working with another
2
 
====================
3
 
 
4
 
Peer-to-peer rocks
5
 
------------------
6
 
 
7
 
In many cases, two minds can be better than one. You may be the one
8
 
who started a project and someone wishes to help, or perhaps it's you
9
 
who wants to help another. Perhaps you are both members of a larger
10
 
team that have been assigned a task together as pair programmers.
11
 
Either way, two people need to agree on a process, a set of
12
 
guidelines and a toolset in order to work together effectively.
13
 
 
14
 
Imagine if you were not allowed to call someone on the phone directly
15
 
and the only way to talk to them was by registering a conference call first?
16
 
Companies and communities that only share code via a central VCS
17
 
repository are living with a similar straitjacket to that every day.
18
 
There are times when central control makes a lot of sense and times
19
 
when peer-to-peer rocks. Either way, Bazaar is designed to help.
20
 
 
21
 
The partner workflow
22
 
--------------------
23
 
 
24
 
While it's certainly not the only way to do it, the *partner workflow*
25
 
below is a good starting point for a pair of people who wish to
26
 
collaborate using Bazaar.
27
 
 
28
 
.. image:: images/workflows_peer.png
29
 
 
30
 
Over and above the tasks covered in the previous chapter, this
31
 
chapter introduces two essential collaboration activities:
32
 
 
33
 
 * getting a copy of a branch
34
 
 * merging changes between branches.
35
 
 
36
 
Even when it's just you working on a code base, it can be very useful
37
 
to keep multiple branches around (for different releases say) and
38
 
to merge changes between them as appropriate. Your "partner" may indeed
39
 
be yourself.