> -----Original Message-----
> From: Ben Collins-Sussman [mailto:sussman@collab.net]
> Sent: 20. marts 2004 14:40
> To: Casper Hornstrup
> Cc: dev@subversion.tigris.org
> Subject: Re: Svn merge URL -> URL?
>
> On Sat, 2004-03-20 at 03:49, Casper Hornstrup wrote:
> > Are there any technical reasons for not being able to merge changes
> > without using a working copy?
>
> Certainly... there's simply no AI good enough to know how to
> resolve conflict markers automatically.
I knew you would say that ;-) How about if the user can guarantee that no
conflict will occur, would you implement it? Is it difficult to implement?
Obviously, if Subversion detects a conflict the merge should be aborted.
I'm experimenting with continuous integration using Subversion. Below is a
description of my thoughts on this. Merging without using a working copy could
save some time. I'm currently implementing a prototype implementation to see
what kind of trouble I run into.
Casper
Goals:
* Make sure that the code base always builds
* Make sure that the code base always passes all tests
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). Simple testing suggests that
Subversion handles this fine (no merge conflicts occur), but more testing is needed to
be sure.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Mar 20 15:55:50 2004