[ros-kernel] New development model
Jason Filby
jasonfilby at yahoo.com
Sun Mar 14 02:45:58 CET 2004
Hi Casper
This is definitely the way to go. Samba does something similar - and
their model seems to have matured somewhat - perhaps we could learn
from
their experience:
http://build.samba.org/about.html
Cheers
Jason
Casper Hornstrup wrote:
>Hi all.
>
>
>
>Below is a description of a possible new development model for
ReactOS. A
>
>new development
>
>model is needed since the current does not work very well. If you
have any
>
>comments on this
>
>or comments about what you would to see in a new development model,
please
>
>post them here.
>
>
>
>Casper
>
>
>
>
>
>Goals:
>
>* Make sure that the code base always builds
>
>* Make sure that the code base always passes all tests
>
>
>
>Continuous integration
>
>======================
>
>For background information on continuous integration go to:
>
>http://www.martinfowler.com/articles/continuousIntegration.html.
>
>
>
>In many open source projects, developers have come to expect that
the latest
>
>sources are unstable and may not even build. Many projects even
provide
>
>releases that have the word "unstable" in the filename. We say this
is not
>
>needed and we'll do our best to always keep the code base as stable
as
>
>possible
>
>through good development practices and continuous integration.
>
>
>
>Subversion repository layout:
>
>
>
> trunk/ ...... Latest development sources. Changes from branches
>
>usually
>
> ends up here.
>
>
>
> branches/ ... Development branches used for developing parts of
>
>ReactOS
>
> without interference from unrelated changes.
>
>
>
> checkin/ .... Intermediate storage for patches. Patches are usually
>
> committed to a branch located here before they are
>
>merged to
>
> the trunk or other branch. The continuous integration
>
>system
>
> will monitor this directory and detect any changes.
If
>
>it
>
> detects a change on a branch then it will checkout a
>
>copy with
>
> that change included, build it, run tests and if it
>
>succeeds,
>
> it will merge the change into the trunk or other
>
>branch.
>
>
>
> tags/ ....... Tags used for tracking revision numbers of releases.
>
>
>
> vendor/ ..... Vendor branches used for tracking third party
>
>software.
>
>
>
>The trunk branch is special only in the way that it is located in
trunk
>
>instead of
>
>in branches/trunk and in that it contains what is perceived as the
*latest
>
>sources*.
>
>
>
>Only a few *repository maintainers* will have write access to areas
other
>
>than checkin/.
>
>These are the only developers who can make changes that does not
need to go
>
>through
>
>the continuous integration system. Such changes should be minimized
and
>
>developers
>
>should be very careful when making them, but it may be necessary in
some
>
>cases.
>
>
>
>checkin/ has the following layout:
>
>
>
> trunk/ ...... Latest development sources that may not pass the
tests
>
>and
>
> may not even build.
>
>
>
> branches/ ... Development branches used for developing parts of
>
>ReactOS
>
> without interference from unrelated changes. These
may
>
>not
>
> pass the tests and may not even build.
>
>
>
>A branch beneath the checkin directory is called a mirror branch.
>
>Checkin/trunk
>
>is the mirror branch of trunk and checkin/branches/<branch> is the
mirror
>
>branch
>
>of branches/<branch>.
>
>
>
>The continuous integration system will monitor the checkin directory
and
>
>detect
>
>any changes. If it detects a change on a branch (checkin/trunk or
>
>checkin/branches/<branch>) then it will checkout a copy with that
change
>
>included,
>
>build it, run tests and if it succeeds, it will merge the change
into the
>
>trunk
>
>(trunk) or other branch (branches/<branch>). In case the change
broke
>
>something
>
>we don't want to be broken (eg. causes the project to not compile or
causes
>
>a test
>
>to fail) then the continuous integration system will automatically
revert
>
>the change instead of merging the change into the trunk or to
another
>
>branch.
>
>Since no information is ever lost in a Subversion repository then
any
>
>reverted
>
>changes can always be retrieved again later. The reverted change
will just
>
>not be
>
>present on the head of the branch.
>
>
>
>During normal operation, all changes to trunk or branches/<branch>
will be
>
>merged
>
>from checkin/trunk or checkin/branches/<branch> by the continuous
>
>integration
>
>system. In the event that a repository maintainer will need to make
a change
>
>to
>
>trunk or branches/<branch> directly then care must be taken to merge
the
>
>corresponding
>
>change to checkin/trunk or checkin/branches/<branch> manually. Doing
this
>
>will
>
>prevent conflicts from occuring when the continuous integration
system
>
>performs
>
>its merging operations.
>
>
>
>Making changes
>
>--------------
>
>When developing a change, a developer usually alters a working copy
made
>
>from trunk
>
>or another branch located at branches/<branch>. The branch is
considered
>
>stable
>
>(since all changes to it passes all tests) so the developer can
update his
>
>working
>
>copy with changes made to the branch after the last update without
fear of
>
>the
>
>working copy being ruined by these new changes.
>
>
>
>When the change is developed and tested, the working copy is
switched over
>
>to the
>
>corresponding mirror branch beneath the checkin directory (using svn
>
>switch). For
>
>trunk this is checkin/trunk and for other branches this is
>
>checkin/branches/<branch>.
>
>When switching over the working copy, all differences between the
branch and
>
>it's
>
>mirror branch are merged into the working copy. The change made to
the
>
>working copy
>
>by the developer will be preserved and there may occur merge
conflicts which
>
>the
>
>developer must resolve manually.
>
>
>
>If the developer don't mind taking the risk of the working copy not
being
>
>able to
>
>be built or not pass all tests after an update, the developer can
work
>
>directly on
>
>the mirror branch beneath the checkin directory. During the time
that passes
>
>from a
>
>change is committed to a mirror branch in the checkin directory,
until the
>
>continuous
>
>integration system reverts the same change that causes the system to
not
>
>build or a
>
>test to fail, the mirror branch is considered unstable. Working
directly on
>
>a mirror
>
>branch beneath the checkin directory can save the developer from
having to
>
>switch
>
>the working copy over before committing a change.
>
>
>
>When the working copy is moved to a branch beneath the checkin
directory and
>
>all
>
>merge conflicts (if any) has been resolved, the developer can check
in the
>
>change
>
>(using svn commit). After the change is checked in and the modified
system
>
>passes
>
>all tests then the working copy can (if desired) be switched back to
the
>
>corresponding (stable) mirror branch again. If the modified system
does not
>
>pass
>
>all tests then the developer will receive a mail containing
information
>
>about what
>
>went wrong. The modified system might not be able to be built or a
test
>
>might have
>
>failed so the change is automatically reverted. The developer can
examine
>
>the
>
>information in the mail, correct the problem, and then check in the
modified
>
>change.
>
>
>
>Problems with this approach:
>
>
>
>* If the continuous integration system reverts a change (A) and
another
>
>change (B)
>
> (which touches the same lines) has been checked in to the same
mirror
>
>branch after
>
> change (A) was checked in (but before change (A) is reverted) then
there
>
>will be a
>
> merge conflict.
>
>
>
> Possible solutions:
>
> A) Commits are serialized. No other commits are allowed during the
time it
>
>takes
>
> for the continuous integration system to checkout, build, run
tests and
>
>revert
>
> a change or merge it to a stable branch. This solution does not
scale
>
>very well
>
> and may frustrate developers.
>
>
>
> B) The files and directories modified by a change are locked down
during
>
>the time it
>
> takes for the continuous integration system to checkout, build,
run
>
>tests and
>
> revert the change or merge it to a stable branch. When a change
is
>
>comitted to a
>
> mirror branch in the checkin directory, a pre-commit hook
script will
>
>examine the
>
> transaction and lock down the modified files and directories
making
>
>them read-only
>
> by all users except the continuous integration system. All
further
>
>commits that
>
> will modify one or more read-only files or directories will be
aborted
>
>and the
>
> developer will have to commit his change later when the
continuous
>
>integration
>
> system has finished processing the previous change. When the
continuous
>
>integration
>
> system has either reverted the change or merged it to the
correct
>
>stable branch, it
>
> will unlock the files and directories belonging to the revision
that
>
>corresponds to
>
> the change it has just processed. The information about the
locked down
>
>files and
>
> directories can be stored in a database or in the Subversion
repository
>
>as metadata.
>
>
>
>* After a developer has checked in a change to an (unstable) mirror
branch
>
>beneath
>
> the checkin directory and swithes over to the stable branch there
may be
>
>merge
>
> problems (check how Subversion handles this). Update: Simple
testing
>
>suggests that
>
> Subversion handles this fine (no merge conflicts occur).
>
>
>
>_______________________________________________
>
>Ros-kernel mailing list
>
>Ros-kernel at reactos.com
>
>http://reactos.com/mailman/listinfo/ros-kernel
>
>
>
__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com
More information about the Ros-kernel
mailing list