incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dennis E. Hamilton" <dennis.hamil...@acm.org>
Subject RE: [Code] strategy for "child works spaces"
Date Sat, 19 Nov 2011 15:45:00 GMT
This is not my area of expertise by any means.  

And I have a concern that this is topic is being over-simplified.  This description is to
test my own understanding of what it takes.

 - Dennis

WORKING A FEATURE BRANCH

The following scenario assumes that it is being performed by a committer, and if multiple
committers are working on it, they are very careful in how they avoid collisions.  I am going
to describe this from the perspective of a single committer who is ensuring integration of
a feature while working on it and before ever merging it into the main tree.
 
For developing a feature on a branch, there is the problem of being able to test it in a build,
and that means there has to be a build tree where it appears to be integrated.  If the build
tree has to be modified to integrate the feature, there is even more source of errors and
problems when it is time to roll the feature into the trunk or main or wherever the mainline
truth is.  (My understanding is that the Podling SVN will not allow unresolved collisions
to be checked-in, but it is also essential not to end up with a broken build.)

With SVN, test builds are preferably done in working copies.  If there is extensive work,
this working copy is perhaps also checked into a "local" SVN or any other source-control system
so that local reversion can be done before the next build with updated feature-branch code.
 

The local working copy of the main tree needs to be kept current, either by updating or doing
a fresh check-out.  Then the feature branch is re-integrated with the local working copy for
a new test build.  Ideally, it is done in a way where collisions with other changes on the
main tree are found and resolved at once, with the feature branch updated to eliminate its
origination of any collisions.  (I have not connected all the dots here.  It depends on how
long feature development takes and how much of the main tree has to be touched.)

That way, the working copy of the feature branch is kept collision free (for now) relative
to the main tree in which it was last synchronized for an integrated build.  The working copy
of the feature branch is checked in to the Podling SVN feature branch regularly and especially
after any reconciliation with the main tree that was done to confirm build integration.

When it is time to put the feature into the main tree, the feature files can be integrated
a working copy of the main tree that is then checked-in.  Collisions at this point will be
rare and, fortunately, have to be resolved before the check-in can be completed.

Obviously, the more carefully the main tree is organized, with the ability to deal with features
at a module or library level with slowly-changing interfaces among modules, the easier all
of this becomes: there is less of the main tree to worry about collisions in. 

OK, too many words and pictures would help.  The simpler and more localized the feature, the
better, obviously.


-----Original Message-----
From: Pedro Giffuni [mailto:pfg@apache.org] 
Sent: Saturday, November 19, 2011 06:23
To: ooo-dev@incubator.apache.org
Subject: Re: [Code] strategy for "child works spaces"

Hi Mathias;

--- On Sat, 11/19/11, Mathias Bauer <Mathias_Bauer@gmx.net> wrote:
...
> 
> We have used them. At that time they where a PITA as
> updating them from the master or integrating them
> into it was very time consuming and required a lot
> of manual merging work. That worked much better
> with Mercurial, but that's not an option now, I know.
> 

I see. Integrating branches on SVN is said to be painful
but to be honest there will always be many people that
prefer perforce, or git or even CVS (really!). There is
no such thing as a perfect tool.

>From my reading CWSs are actually branches, and the one
thing we really lost is EIS, but I think using SVN branches
directly can be very useful.

I think we could use a SVN branch as a buffer to integrate
CWSs one by one; that way we don't interrupt current work
and get to try the CWSs before the tree changes too much
to make merging difficult.

Creating branches is very easy and any committer can do it.
Is there a way to get CWSs as diffs?

cheers,

Pedro.
 

> We probably might want to reserve work on branches for
> larger code
> changes that require weeks or months, but integrate smaller
> changes
> directly into the master in a CI style with daily builds.
> 
> Regards,
> Mathias
> 


Mime
View raw message