OpenOffice.org source control
OpenOffice.org main codelines
OpenOffice.org does use the cvs Source Control System. The major releases of OpenOffice.org are implemented on, so called, cvs branches. The development of the next major releases is developed on HEAD of the cvs tree, the maintenance of older versions also happens on branches.
In
the OpenOffice.org environment these branches are often called
codelines or master(-branches). Builds on these codelines does not
happen continuously (daily builds) but within regular milestones. For
the 1.1.x codeline this result in a cvs branch tag called mws_srx645
which represents the latest status of this codeline and several more
tags which represent a specific milestone on this codeline
(SRX645_m34, SRX645_m40). The same scheme applies to the 2.0 codeline
(mws_src680 for the latest status, SRC680_m36 for a specific
milestone). Usually every week there will be a new milestone on the
active development line available. There is also the possibility to
achieve some more granularity with the introduction of steps, so that
more than one build per week is possible (SRC680_m33s1).
The names like SRC680, SRX645 will be deprecated in the future, they represent the old scheme of milestone naming.
As soon as the OOo 2.0 comes close to release, a new branch for this codeline will be created so that concurrent development of the next release can be started.
Development branches
Since OpenOffice.org build times are pretty high and the goal is to have at all times a milestone available which is in release quality, no commits to the master codeline are made. OpenOffice.org is developed by more than 100 developers, it builds for more than 10 platforms, for more than 25 languages and it has more than 7 million lines of code with a plenty of build time needed for a complete recompile. So the risk of breaking something is pretty high, even if the comitters is sure about his changes. Due to this complexity we introduced the concept of doing any feature development and bug fixes on cvs branches. This means that a new feature has to be developed on a cvs branch, until the feature is complete and has been tested on at least to major platforms (usually one Unix derivate and Windows). The same applies for bugs fixes, but bug fixes should be grouped together on one branch.
These
branches are called within the OpenOffice.org environment child
workspaces. Since it is possible to create many child workspaces
in parallel, some additional processes has been developed to make
life more easy and secure on these child workspaces. For example, the
problem of “repeated merges” is quite common in cvs. This
situation occurs quite often when dealing with many branches in
parallel, for example if a bug fix has been applied to more than one branch.
Child workspace resynchronization
Many of the “repeated merge” problems can be solved before the merge back to the master branch if you were able to bring your copy of the cvs branch up to date of the latest know stable version of your master. For this the resynchronization action (cwsresync) command has been introduced.
The
resync mechanism is able to deal with repeated operation, so that
this process can be executed frequently. In case a conflict has to be
resolved, this will happen in the child workspace, so the risk of
having a broken master workspace is less than in the classical
approach, when a branch will be merged back to the master with the
usual 'cvs update' command.
Child workspace reintegration
When all the changes being made on a child workspace are joined back, the log history of the branch will be saved and stored in the log history of the trunk as well. Otherwise the tracking of what had happened on a branch is difficult.
Since the reintegration is always done by a unique entity (usually Release Engineering associated with this codeline) we loose the ability to see the original author of a single line with the 'cvs annotate' command, but we still are able to see when a line of code has been changed and can use the log for getting more details.
revision 1.38
date: 2004/04/02 13:49:24; author: rt; state: Exp; lines: +9 -1
INTEGRATION: CWS sj05 (1.34.80); FILE MERGED
2004/03/15 13:47:50 sj 1.34.80.4: RESYNC: (1.36-1.37); FILE MERGED
2004/02/13 17:38:38 sj 1.34.80.3: RESYNC: (1.34-1.36); FILE MERGED
2004/02/09 15:01:36 cl 1.34.80.2: #i20484# added new CustomShape ui
2004/02/04 11:39:15 cl 1.34.80.1: #i20484# added new CustomShape ui
----------------------------
revision 1.37
date: 2004/02/25 15:55:41; author: kz; state: Exp; lines: +0 -10
INTEGRATION: CWS layoutmanager (1.34.20); FILE MERGED
2004/02/19 16:33:04 cd 1.34.20.3: RESYNC: (1.35-1.36); FILE MERGED
2004/01/29 16:56:22 cd 1.34.20.2: RESYNC: (1.34-1.35); FILE MERGED
2003/11/24 07:25:16 cd 1.34.20.1: #111899# Remove old menu controller registration
----------------------------
revision 1.36
date: 2004/02/03 16:35:11; author: hr; state: Exp; lines: +17 -12
INTEGRATION: CWS dialogdiet (1.34.60); FILE MERGED
2004/01/26 14:32:05 mba 1.34.60.3: #i22972#: SvxErrorHandler needs to be created by apps
2004/01/19 23:47:01 mba 1.34.60.2: RESYNC: (1.34-1.35); FILE MERGED
2003/11/28 18:08:12 mba 1.34.60.1: #i22972#: offmgr removed
Environment Information System (EIS)
There is a web frontend to view a list of child workspaces and their status ( http://eis.services.openoffice.org/EIS2/servlet/GuestLogon). The status of a child workspace and the corresponding master workspace can be viewed.