Replacing an expensive proprietary CM system with bzr.

[Jurgen Defurne]

I am currently doing an investigation to see if it would be possible
(long term) to replace a commercial CM solution with a combination of
Bazaar and mySQL. I only need to focus on Bazaar, since a whole lot of the bug tracking is currently supported by mySQL for caching and speed.

* Proprietary solution drawbacks
** Every operation is slow (> 1s).
   Although automation is possible, this does not offset its slowness,
   especially as the volume of source code grows every year. Release
   operations currently need from 2 to 4 hours. This is on a source
   tree of 5 Gb, which contains the equivalent of 211 checkouts in a
   NestedTree.
** Expensive. The amount of money saved could certainly be used to hire
   at least one developer to fully support bzr.

* Necessary features for switching from the other system to bzr
** Graphical interface in Windows : context menu like TortoiseSVN
** Integration of bug tracker and VCS via graphical interface
** Good graphical history view of objects
** NestedTreeSupport
** How does Bazaar handle databases of 80 Gb and more ?
   The main question here is, how can you improve on the speed of the
   central repository when several developers at once are doing
   updates or checkouts ? When the build manager is tagging 211
   different checkouts in one tree ?

** Daily build and acceptance work-flow description

   Developers check out their private checkout, and use it for
   development.

   At the end of the day a program starts an update and a build. In
   the morning, the test team checks the build
   results and gives later in the day the go ahead to say that the
   particular revision is allright. However, as part of the build,
   there may be libraries and executables taken in, which need to be
   committed. Does this mean that prior to daily acceptance no one may
   commit, or is there another solution possible with bzr ?

   After daily acceptance, it should be possible to say to the
   developers to which revision they may update their checkout.

   Developers are responsible for merging their work against the
   latest accepted (promoted) status.
** Multi-site work flow description
   Daily check-ins are not sent to each repository. Rather, all
   projects get assigned responsibility to one subsystem, and these
   are developed in the context of other subsystems. There is a weekly
   release. This weekly release should be taken into the other
   repositories. The biggest problem with this part is the deletion of
   objects.

  I suppose that in the case of daily-build and multi-site work flow,
  the solutions are laying in the distributed development model of
  bzr. In this case, I should probably first do a comparison of terms.

| Proprietary | bzr                   |
|-------------+-----------------------|
| database    | repository            |
| project     | light-weight checkout |
| version     | revision              |

  The other system has an export mechanism which makes it possible to
  pack a certain revision of a project into a package which can be
  transferred to another database and recreated there. This mechanism
  can be used differentially, in which case it is possible to send
  only deltas between the originating and the receiving databases. I
  suppose the only available mechanism in lieu of this is probably
  diff and patch.

  I should be running checks to see which transport mechanism is the
  fastest. I have already established that the file:// protocol, over
  a CIFS share is very slow.

** The way access rights have to be assigned to a repository is not
   clear
   Especially since I am now doing experiments in a Cygwin environment,
   I got twice problems with locks which could not be removed from the
   repository after doing a checkout.

I hope to have a good discussion about this in this mailing list.

Regards,

Jurgen