On Thu, Jan 13, 2005 at 12:59:39PM -0800, Stephen McConnell wrote:
> I figure that one uses the "trunk" branch for main
> codeline development. Developers can create their own
> branches to work on specific problems, but they can only
> merge the branch or code from the branch into trunk
> when it has been tested in their private workspace.
> (I still only commit my code to trunk once I've tested
> it completely in my private workspace.)
Okay - so since your using the SCM Patterns book, I'll use
the names of patterns from the book.
It seems your developers are either already using a
Task-Branch for a specific fix/feature/enhancement,
or else you're contemplating using one. If not, developers
could still work on a "Private Branch" (which is like
a task-branch, but can be long-lived over the lifetime
of multiple tasks performed by that developer).
So the granularity of merging for a given change is
either the entire branch (for a task branch), or else
a particular "commit" to the codeline. In either case,
the result of committing the changes on the Private/Task
Branch to the development team codeline (the "Active
Development Line") will result in a specific SVN
revision number. You can use SVN properties to associate
a name (and status if you like) of that revision number.
You could even maintain the list of files changed as
a property associated with that revision number (not
sure if you really need that or not).
Each "commit" to the Active Development Line represents
a new fix/feature/enhancement. After a series of commits,
you will have accumulated multiple changes since the last
test. Here you have a choice to make about how you decide
what to promote (submit) to the QA/Test area:
1) you can use a property to assign a "Test-Ready" status
to a particular version on the Active Development line
* This will tell QA/Test which versions of the codeline
they should test, and which ones they should ignore.
* Once QA/Test has tested a Test-Ready version of the
codeline, then can "promote" the Test-Ready status
to be "Tested" or "Production Ready" -- it depends on
whether or not all Tested versions go into to production,
or if they are batched together (in which case only
use "Production Ready" status for the Tested ones that
goto production)
2) You can use a "Test/QA" Branch, and promote to it
by merging selected (e.g., Test_Ready) versions of
the Active Development Line to the Test/QA Branch.
* When a Test/QA Version is production-ready, you can
promote it my "merging" it to the Production Branch
Method #1 probably looks more complex than #2 because
#1 uses properties on a single codeline to indicate
which versions are ready for and/or have passed the
next promotion level.
- You can use a single property with a value
corresponding to a progression of states,
- Or you can use a boolean-valued property
per promotion level to indicate whether or
not a given version has attained that level
(the result is more properties to deal with,
but you can easily see if any "levels" were
skipped for a given version)
Method #2 uses promotion branches and is probably closer
to what you are reading about in the SCM Patterns book,
The main difference is that here, instead of just
an Active Development Line *and* a Release-Line, you
the two for your intermediate promotion level. The
result is:
Active Development Line ==> Development-Team
Test Codeline ==> Test/QA
Release Line ==> Production
If you merge from codeline to codeline in this manner,
and always in a sequential fashion, then you shouldn't
have to worry about repeated merges.
If you use a SVN workspace for each "area", then when
you promote changes from branch-to-branch, you do so
be doing an "update" in the integration "sandbox" for
that promotion branch, and then commit changes when
your are done. Only the files that really and truly
changed should get updated in the integration workspaces.
If you still have problems with rebuild times/accuracy
for your JAR and WAR/EAR files, then you could conceivably
add a post-commit hook to each codeline that sets a
property on that newly committed revision and have the
property value be the list of files that were modified
as part of the commit. You can than use that to find
the set of files that changes between two versions
on the same codeline.
Hope that helps! Let us know how it goes!
--
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
Received on Sun Jan 16 00:41:12 2005