Re: "Floating" tags and automating the build process

Hi Scott!

If I understand you correctly, in your implementation of the
Active-Development-Line + Release-Line patterns, you have a "feature
branch" as your "active development line" and are using the "trunk" as
your release-line. Is that correct?

So you are doing feature (and feature-team?) integration work on the
feature branch, and running (ideally?) the same set of tests for the
integration branch and the trunk. And you are wondering about some
issues that arise with synchronization (or lack thereof) of changes
between the trunk and the feature branch. Do I have that right?

If so, I suspect that something similar to "workspace update" would be
used. If Im working on a private/task branch, standard best-practice is
to have some means of ensuring my changes are somehow up-to-date withthe
codeline before I checkin to the codeline from my branch. This is
typically done either by doing an update (a.k.a. "rebase") from the
codeline into my branch, or else by first merging my task-branch into an
integration workspace and resolving conflicts their before checkin to
the codeline.

There is a need for a similar "setup" between your feature branch and
the trunk. Before you merge your feature-branch to the trunk, you want
to do something similar to a "rebase" from the trunk into your feature
branch, to catch all the latest changes from the trunk and
resolve/stabilize them before merging the latest state of the
feature-branchg to the trunk.

Rebasing (merging) from the trunk to the feature-branch prior to
committing to the trunk is one way to do this. If you are okay with
rebasing (workspace update) from the feature-branch into your private
workspace prior to committing changes to the feature-branch, then you'll
simply do the same thing (update/rebase) between the feature-branch and
the trunk that you would do between a private-task branch and the
feature-branch.

Scott V. McGuire wrote:
> On Wed, May 04, 2005 at 01:46:17AM -0500, Brad Appleton wrote:
>
>>
>>Weintraub, David wrote:
>>
>>
>>>In the stable head model, all developers develop off of a private branch
>>>and not off of the head of the main branch.
>>
>>[... snip ...]
>>
>>>Either that, or have a "build" branch and let the developers work off of
>>>the trunk. Then, when they finish, they can merge onto the build branch.
>>
>>This is the pattern pair known as "Active Development Line" and "Release
>>Line" from the SCM Patterns book (www.scmpatterns.com). Development has
>>their own codeline for integration and they use the tip. The formal
>>CM/Build/Integration group has their own codeline to which the
>>merge+build only "good/stable" stuff.
>
> ... elision ...
>
> I can't let this opportunity go by: one of the authors of the software
> I'm using (well done!) and one of the authors of a book I recently
> read (well done too!) to help me decide how to use it both in a thread
> related to a question I've been meaning to ask. :)
>
> I think I am missing a step in how to get this pattern to work using
> subversion, or I'm making it more complicated than it needs to be. As
> I see it, a possible sequence of events is
>
> 1. Create a feature branch.
> 2. Do some development work and commit it to the branch.
> 3. Repeat step 2 until the development work is done and passes
> required tests.
>
> Here is where I see the problem starting. We have some quality
> requirements for the trunk: that some set of tests must always pass.
> Lets assume that this is the same set of tests we used in step 3.
> Even though they pass on the branch, they might fail if this branch's
> changes were merged into the trunk because other changes might have
> happened to the trunk since this branch was created. So,
>
> 4. Merge changes which happened in the trunk since the branch was
> created into the branch.
> 5. If necessary commit more changes to the branch so the tests pass
> again.
> 6. Possibly go back to 4.
> 7. Merge from the branch to the trunk.
>
> Now aren't there going to be problems with this merge? Since the
> branch already contains the changes which happened on the trunk during
> the branch's lifetime, won't Subversion attempt to apply them a second
> time to the trunk? And isn't this bad?
>
> Thanks,
>

-- 
Brad Appleton <brad@bradapp.net> www.bradapp.net
    Software CM Patterns (www.scmpatterns.com)
    Effective Teamwork, Practical Integration
"And miles to go before I sleep" --Robert Frost
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org