[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-11 04:14:52 CEST

Hi Brad,

On Mon, May 09, 2005 at 09:41:22AM -0500, Brad Appleton wrote:
> 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?

My feature branches were meant to correspond to the Task-Branch
pattern from the book. Actually, I had been calling them task
branches until a few days ago. I guess I should have stuck with it.
Our full test suite for releases is too much to run before every
update to the trunk, so we will still have release branches. With the
testing we will require, I'm aiming to keep the trunk "near
releasable". Ideally, when we branch before a release we will find
that the trunk was, in fact, release quality.

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

There will be feature teams which is why I want feature branches
rather than just private branches. Before updating the trunk, the
developers will run the same tests on their feature branch that we run
nightly on the trunk.

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

Right. In our case we want to go for the update/rebase. So, here is
what I'm worried about (in horrible ASCII art :). We have two feature
branches off of the same initial state of the trunk, T0. Branch 1
merges first, adding the update F1 to the trunk. Prior to merging
branch 2, we update from the trunk (and run our tests) leaving us like

Feature 1: T0 + F1
             / \
Trunk : T0 -------- T0 + F1 -----------
             \ \
Feature 2: --- T0 + F2 --- T0 + F2 + F1

Now if I merge branch 2 into the trunk, will the trunk end up in state

T0 + F1 + F2

as it should? Since we've been warned in the Subversion books that
Subversion doesn't do merge tracking and that merging the same update
twice is bad, I fear ending up with:

T0 + 2 * F1 + F2.


> ... elision ...


Scott V. McGuire
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed May 11 04:17:12 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.