[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: "Floating" tags and automating the build process

From: Scott V. McGuire <smcguire_at_nyc.rr.com>
Date: 2005-05-07 01:12:58 CEST

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
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?


Scott V. McGuire
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat May 7 01:15:15 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.