Revision 1 as of 2006-06-18 12:07:49
|Deletions are marked like this.||Additions are marked like this.|
|Line 53:||Line 53:|
''(Note: the above command does not currently work due to "checkout" requiring a writable source to lock. Until this is fixed, you can either use a writable source (such as sftp://...) or the "bzr branch" command followed by a "bzr bind" command.)''
This tutorial is for people that are experienced with SVN. Its generally better to start off with the normal tutorials if you do not have experience with SVN.
This tutorial is broken up into two sections; concepts and behaviour. The concept section is concerned with giving you the understanding to run Bazaar-NG effectively. The second section eschews all of the details about what and why things are and jumps straight into the usage of Bazaar-NG.
If you learn better with a hands on approach, then skip straight ahead to section 2. If, on the other hand, you are the sort of person that likes to think a bit about things before you do them, then section 1 is for you.
Section 1 - Explanation of Bazaar-NG
Whats that hype about?
So, by this point you've probably gotten it from all sides about how you need to give decentralized revision control systems like Bazaar-NG a try. "Bazaar-NG does this! It does that too! It can merge this, allows for independent development that, tracks history the other, and generally makes hacking fun again". For all the hype that you hear, Bazaar-NG probably finds lost socks as well.
So can Bazaar-NG really do _all_ of these things? Nope. Its a lie. Bazaar-NG will not find the sock that slipped behind your washing machine. The rest of it is true beyond a doubt.
What is DRCS all about?
Project management used to be highly centralized. People working together on a project would meet together in one place, work together on a project and release their work. If you didn't work in the same place, you were an outsider that at best could send in patches.
To say that the world has changed since the internet became ubiquitous is an understatement. Developers for free software projects are spread throughout the world. Wouldn't it make sense if our development tools worked the same way that we do?
How is a branch different from a SVN repository?
The purpose of decentralized revision control systems is to break the chain between the developer and the server. This is done by moving the RCS data from the central server down to the developer. This is done by making a Bzr branch something that is like both a repository and a working tree.
Logically combining the RCS data with the working tree means that when you branch from somebody else, you end up with a repository of your own. That means you can commit in your branch without needing to ask for permission from the person you branched from. Its almost as if you copied their SVN repository and made a SVN repository of your own.
How do repositories fit into the Bazaar-NG model?
The catch to keeping RCS data and working trees logically related is that each time you make a branch, you copy a lot of RCS data. Some revision control systems, such as Bazaar-NG, allow one to create a shared repository. A shared respository allows the user to store the RCS data for several branches in one place. That way, the RCS data common to several branches is only represented once on the filesystem.
How does merging work between branches?
Section 2 - Common SVN behaviours translated into Bazaar-NG
This section explains how to perform common SVN behaviours in a Bazaar-NG world. Unfortunately, this means that I won't be able to teach you many of the things that are unique to decentralized revision control systems.
This section covers how to use Bazaar-NG in checkout mode. Reading section 3, which covers standard Bazaar-NG methods, is highly encouraged.
Getting a checkout
In the SVN world, somebody has already setup a SVN repository and has told you a URL to "checkout". You checkout with:
$ svn checkout URL
- Usually the URL is a svn:// url, like the below example:
$ svn checkout svn://somemachine.com/this/directory/here
However, in the Bazaar-NG world, this is usually done with:
$ bzr checkout http://somemachine.com/this/directory/here
(Note: the above command does not currently work due to "checkout" requiring a writable source to lock. Until this is fixed, you can either use a writable source (such as sftp://...) or the "bzr branch" command followed by a "bzr bind" command.)
Updating a checkout
In the SVN world you may have done a checkout. From time to time you have to get new changes from the repository and apply them to your checkout. This usually looks something like this:
$ cd codebase/ $ svn update
This looks very similiar in the Bazaar-NG world:
$ cd codebase/ $ bzr update
In both the CVS and Bazaar-NG case this will mean that the changes in the repository or branch that you do not yet have in the working tree will be applied. You might have to deal with conflicts.
Seeing how a working tree has changed since the last commit
In the SVN world we often want to check how we have changed things since we last committed. By checking how the code base has changed, we can see what we're about to commit before we actually perform the commit.
In the SVN world, we would check the changes this way:
$ svn status [see a list of files that have changed] $ svn diff [see a diff of how files have changed]
This is very similar in Bazaar-NG:
$ bzr status [see a list of files that have changed] $ bzr missing [see a list of new revisions in the parent branch] $ bzr diff [see a diff of how files have changed]
In both of these cases, you'll get a diff that you can review prior to commit.
Comitting code in a checkout
In the SVN world you may have made changes to your checkout that need to be saved in the repository. One typically does so in this way:
$ svn commit -m'some description of whats being committed.'
Again, this looks very similiar in the Bazaar-NG world:
$ bzr commit -m'some description of whats being committed.'
In both of these cases, the new changes will be saved to either the repository (SVN) or branch (Bazaar-NG).
Section 2 - Using Branches to perform SVN migration
Bazaar-NG supports a variety of other development methodologies that are foreign to SVN developers. These methodologies typically work much better than the SVN method. They are, however, a bit different from the CVS way.
Section 3 - Development methodologies
Loose Cannon Style
- Each developer makes and maintains their own branches.
- Developers merge each other ad-hoc
- No coordination of merges between branches
- Everyone gets their own itches scratched
- Developers do not need to like each other
- Highly competitive environment.
- Branches will become highly diverged.
- Users will be confused about which branches to follow
- Branches will likely diverge into different projects
Shared Branch Style
- There is one proto-branch that all developers can push to and from
- Developers may have local branches that individual features are worked on and then merged into the proto-branch
- The branch for users to follow is clear and obvious
- Development is not held up if one developer goes on vacation
- Developers can put code into the proto-branch without test cases being run.
- Contention for pushing into the proto-branch may become an issue if there is a large number of commit-happy developers.
The Lieutenant Style
- Needs to be combined with another style of development
- Each developer is responsible for a section of the codebase
- Developer collects merges and patches for their section of the codebase and puts it into a special branch
- Developers can specialize on a particular type of code
- Code is more likely to become peer reviewed
- Coordination for code that needs the involvement between two or more Lieutenants becomes a bit more complicated
- Development rate is slowed down a little.
The Patch Queue Manager Style
- Each developer makes their own branches
- The merge requests are submitted via email to a bot
- The bot merges the developers into the proto-branch
- Development is well coordinated
- Tests can be run automatically.
- Contention is reduced as changes are merged and not pushed
- Depends upon a server that can accept mail and expose a branch publically
- Can fall down under high loads
- Is not well documented