[ros-kernel] New development model
Jason Filby
jasonfilby at yahoo.com
Sun Mar 14 03:36:16 CET 2004
Actually, they differ in that commits are checked in regardless - a
broken build is reported but not rejected.
Cheers
Jason
Jason Filby wrote:
>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
>
>_______________________________________________
>
>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