Bzr

    This article is outdated.    

CWS on Bazaar

Migration of CVS/CWS/EIS to Bazaar

This is the hub page for information related to the migration of CVS/CWS/EIS to Bazaar. Please enter links/information about sources of information, status and working notes.

Quick Status: work in progress

Sources of information on Bazaar:

• Bazaar Homepage
• Bazaar Documentation
• Bazaar Switcher Guides
• Bazaar Migration Guide

How does bazaar meet the requirements for the next OpenOffice.org SCM tool

The preliminary list of requirements is availabe here.

Bazaar and Mandatory requirements

1. The SCM tool and its repository format must be stable enough to support a code base of the size of OpenOffice.org (this is self evident). The best way to prove this is the successful use in other large software projects.
   Bazaar is ready for OOo. bzr's performance is regression tested against the Mozilla codebase (50.000 paths).
   
2. Clients for the SCM tool have to be available for the major development platforms (Linux, MacOSX, Solaris, Windows) and should be available for most of the OpenOffice.org platforms.
   bazaar is available for all required platforms, GUI clients are available for Gtk, Qt, Native Windows, Eclipse plugin.
   
3. The new SCM should support the subset of CVS which is used in every day life, such as "status", "diff", "annotate", "log" etc in a reasonable way. I'm certain that every modern SCM does this, CVS sets the lower bar here.
   See this list of supported commands
   
4. The general operation of the SCM should not be significantly slower than CVS, at least the important things: "commit", "diff", "log" etc. If some seldom used operations like "annotations", "history" are slower than this is probably not much of problem.
   bazaar is substantially faster for these operations (copy of history can be held on the local machine)
   
5. The SCM tool must easily support the concept of branches.
   bazaar does support branches
   
   1. Branch creation must be light weight. We create branches even for one liner fixes in single files (bugfix CWS).
      A branch consists of a single revision pointer and configuration data; it is light weight and constant time.
      
   2. It must be possible to repeately update (resync) a branch to a newer version (milestone) of the trunk or a release branch. We create branches that live for many months with constant work on them (huge feature CWS).
      Bazaar development depends on this feature as well.
      
   3. If the update (resync) operation is expensive (in terms of merge time and repository size) than branching and resyncing must be possible on a subset of the tree, let's say only on a number of modules.
      It is not expensive, however it is proportional to the amount of new work which is not yet integrated in the branch.
      
6. The SCM must easily support the concept of tags
   bazaar commands tag, tags
   
   1. Tag creation must be lightweight. We create regularly new milestones which needs to be tagged (milestone tags). If the repeated update mechanism for the branches requires tagging to prevent multiple merging as CVS does, than this is even more important (anchor tags).
      Bazaar tags are lightweight and stored per branch; tags may be created and deleted at any point.
      
7. There must be an easy way to share changes on a branch even before the branch is ready for integration. There is a need to do cross merging between branches from time to time. Usually not a complete changeset is cross merged but just single selected pieces (pulling selected fixes from another CWS).
   With bazaar a branch can be published at any point and selected commits or portions of a commit merged into other branches.
   
   1. Note: with a centralized SCM tool this requirement is inherent fulfilled, but for a distributed SCM tool this requires the setup of a publishing framework.
8. The pushing of changes into a public visible repository must be adequately secured by an authentication mechanism. We cannot risk someone trying to sneak bad code (back doors, encumbered code, embarrassing stuff) into our code base. OpenOffice.org has now a public visibility that makes that kind of attack more likely and is huge enough that certain code changes might go unnoticed for a long time.
   Bazaar allows repository access via sftp which gives same security as openssh. additionally committts may be gpg-signed.
   
   1. Note: this is also something which comes more a or less natural to a centralized SCM tool but needs to be set up for a DSCM.
9. There must be a way to replicate the "one-and-true" repository into remote r/o repositories to reduce network load.
   Bazaar supports this as a DSCM.
   
   1. Note: now this is one thing that DSCM can do by design but needs to be set up for centralized SCM tools.
10. It must be possible to preserve the history of trunk, all release branches and all active CWS branches during import in the new SCM tool. The import should not take an unreasonable amount of time.
    Should be possible. Really tricky unless we can get direct access to a copy of the repository.
    
11. Proper handling of binary files.
    Bazaar safely preserves binaries.
    

Bazaar and favoured SCM features

1. If the SCM tool is a drop in replacement for CVS.
   Bazaar is an easy transition from CVS: core commands like init, add, merge, commit, diff are similar.
   
2. If the SCM tool allows easy integration in a development framework such as commit messages, correlation of commits with issues etc.
   Bazaar 'commit --fixes' allows association of commits with issues in any issue tracker.
   
3. If the SCM tool plays nice with CEE from collab.net (our site hosting software).See above for integration with the bug tracker.
   
4. If it's enough to modify our CWS tooling to work with new the SCM tool without inventing completely new authentication and publishing schemes.
   Authentication and publishing is similar to with CVS. In addition, branches can be readonly on an http server, or readwrite on an sftp server, needing no special software installed.
   
5. An easy scriptable interface or client libraries with multiple language bindings (Perl preferred).
   Bazaar has an easily scriptable and stable Python library interface, and has also been scripted through the shell interface from Java and Elisp.
   
6. Easily traverses firewalls.
   Bazaar can pass through firewalls on http or ssh.
   
7. A web browsable interface.
   Bazaar has 'loggerhead', a web interface, see an example
   
8. Available Bonsai and Tinderbox integration.
   Unknown
   
9. If it's easy to replicate "the one-and-true" repository at least for r/o access.
   Yes, it's easy to replicate it using either Bazaar or rsync.
   
10. The ability rename/move files with full history preservation.
    Bazaar tracks file, directory and symlink renames correctly, including insertion of new files into previously renamed directories. This is highly useful when extensively rearranging code as is contemplated for OOo 3.0.
    
11. The ability to rename/move directories with full history preservation.
    bazaar ...
    
12. Atomic commits.
    Bazaar commits are atomic snapshots of the tree.
    
13. The repository will be accessed by non-developers, too, thus an understandable interface and good documentation is desirable.
    Bazaar has an excellently usable interface, often complemented by users for its simplicity and approachability compared to cvs and git.
    
14. Ability to handle more heads, and to cross-merge changes
    Bazaar handles repeated cross-merging of changes between development branches.
    
    1. There exist quite a lot of 'flavors' of OpenOffice.org - vanilla up-stream, StarOffice, ooo-build (Novell version, Debian version, Win32 version, ...), MacOSX port, ... The new SCM should be able to handle the scenario where a branch is already merged in one of the heads, but cross-merged to vanilla upstream later after approval. (Easy with DSCM, not sure about centralized SCM.)

Nice to have things in Bazaar

1. Be able to fully work offline.
   Bazaar is fully distributed, but can also work in a adaptive mode where commits are normally immediately pushed to a server, but can be committed only locally when appropriate.
   
2. Familiar commands to reduce retraining effort.
   See the Bzr for CVS Users Guide
   
3. Integration into popular IDEs like netbeans and eclipse.
   Good and actively maintained Eclipse and Visual Studio integration, not sure about NetBeans.
   
4. Before/during the conversion we should change tabs in c/c++ files to spaces (as the current OOo coding standards recommend)
   Not directly supported, but this should be a simple modification to the import script.