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:[email protected]] Sent: Saturday, November 19, 2011 06:23 To: [email protected] Subject: Re: [Code] strategy for "child works spaces" Hi Mathias; --- On Sat, 11/19/11, Mathias Bauer <[email protected]> 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 >
