Re: Subversion and "Configuration Management"

One other thing to note - Nicols wrote:
> > A branch would not do. Labels should be able
> > to be moved from rev to rev in a file.

In essence the approach mentioned below "flips" this around.
The "Promotion Branches" function as "dynamic labels", and
rather than moving the label from rev to rev, it INSTEAD
lets the revs move from label to label (following the old
advice that, if you can't move Mohammed to the mountain,
then move the mountain to Mohammed :-)

---------------------- Original Message ----------------------
On Wed, Mar 31, 2004 at 04:20:09PM -0600, Brad Appleton wrote:
[NOTE: discussion moved to the SVN users list instead of developers list]

Hi Nicols!

What you describe seems to be what is more commonly known as
the concept of "Promotion". In order to do it, one first defines
a "Promotion Lifecycle Model" (or Promotion Model/Cycle).

Typically, a promotion-cycle is a simplified form of state-machine
where I have a more or less linear progression of "promotion
levels" where each one corresponds to a level of higher
"blessedness" (e.g., readiness, stability, acceptance) than
the previous one. So from a given promotion-level, I
can move forward to the next level (promote), or backward
to the previous level (demote), plus "jump" to a terminal
failure/rejected state (or, with appropriate "privilege"
jump prematurely to successful completion state)

The first thing I alway try to grasp when dealing with defining
a promotion model (and implementing it in the CM tools) is
to figure out WHAT is being promoted? For example:
 - is it a particular file revision?
 - is it a group of file revisions (e.g. a change-set)
 - is it a version of the product (or of a component)
 - is it the "contents" of a codeline (branch)

Note ALSO that a promotion-level of an object is usually
context-sensitive. That is to say it depends upon the particular
release. If I maintain multiple releases while also developing
the latest releases, then the "promotion level" of my changes
are relative to the specific release they are targeted to. And
I might need a separate "concurrent" progression of levels to
track the "status" of my change for each parallel release it
will go into (e.g., a fix might need to go into release 2.1.1
and 3.2.1 and also v4.x)

My experience has been that a lot of people and tools try to
define promotion models at the individual file-revision level,
but that this is actually not a very effective way to do it,
and the only reason they try it this way is because that's
how they got used to doing it before they used a tool that
was smart enough to know about change-sets of repository-wide
branches and versions.

Usually, a given software change touches (creates/revises) multiple
files, and that particular "task" isn't done until ALL of it's files
are checked-in (committed), to the appropriate branch with the
appropriate level of testing.

Initially, I think it makes the most sense to associate a
promotion model initially with a change-set. So when you
"commit" your changes the promotion level is associated with
all the file revisions that were part of your "commit".

However, in Subversion, I think it is common to use "task
branches" and so the promotion-level could more easily be
associated with a particular codeline (branch). Hence
the common practice of using "Promotion Branches" or
"Staged Integration Lines" might be your best bet for
promotion modeling with Subversion. See the write-up at:
<http://acme.bradapp.net/branching/branch-structs.html#StagedLines>

For a given release, you could create a "nested hierarchy"
of branches off the mainline (trunk) for that release.
The mainline would be the "last" promotion level, and
the first branch off it would be the "next to last",
and so on. Lets say I have a promotion cycle of
{"PERFORMED", "REVIEWED", "TESTED", "INTEGRATED",
"SCM-BUILT", and "VALIDATED"}

So "VALIDATED" would correspond to the mainline/trunk
for that release (call it Rel3.2). And I might have a
set of branches as follows:
* Rel3.2-Trunk -- contains only validated changes
* Rel3.2-Built -- contains only SCM-built changes
* Rel3.2-Int -- contains only integrated changes
* Rel3.2-Test -- contains only tested changes
* Rel3.2_Rvw -- contains only reviewed changes

So when I first go to make a set of changes, I would
create a Task Branch (call it MyTask). When I finished
my commit(s) to the task-branch, the state of all the stuff
on my branch is "PERFORMED" (I could use PromotionLevel
property on the global revision created by my last commit).
Then eventually I push/port my changes from MyTask to
the Rel3.2_Rvw branch once the changes are reviewed.
Then I port to the -Test branch once they are tested,
and to the -Int branch after that, and then to
the -Built branch, and finally to the -Trunk branch.

Each time I "port" from one branch to the next I might
use a ChangeTask property to associate the name of the
task that was just reviewed/tested/integrated/built/...
with the revision number of the commit (this assumes I do
this ONCE for every task, and that I never "port" more
than one task at a time from branch to branch, otherwise
I might have to record multiple task-names in the value of
the ChangeTask property)

Then an "svn log" command on any given promotion branch should
be able to give you the list of all ChangeTasks that have
reached that promotion-level. (At the end of a release, you
could even do a "parity check" of sorts on all the promotion
branches to make sure that the list change-tasks on the Trunk
are also on each of the other branches)

So I think this would do what you need. Its a bit more
copymerging (porting from branch to branch) than I
personally care for. But I think its one way to do
what you want, and given that "copying" in SVN is
very cheap, and that branches and tags are both
just "copies", it might actually be one of the better
ways to do this using SVN.

Hope that helps! (I know you said a "branch would not do"
below, but I wonder if you had something different in
mind than the above, and that the above really does
meet your need. If you feel it doesn't, can you please
explain why not, and what needs it doesn't meet?)

Cheers!

-- 
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
On Wed, Mar 31, 2004 at 03:35:16PM -0600, Ben Collins-Sussman wrote:
> On Wed, 2004-03-31 at 15:21, Nicolás Lichtmaier wrote:
> > Hi, I will not talk about i18n this time =).
> > 
> > Here where I work we are trying to implement Subversion, when we 
> > previously had used ClearCase. In addition to that, in the following 
> > months we'll be implementing CMM. Has anyone tried to use Subversion in 
> > combination with something like CMM?
> > 
> > Appearantly we need to put labels to objects. A branch would not do. 
> > Labels should be able to be moved from rev to rev in a file. Labels 
> > themselves are not versioned. One such label could be "LATEST_RELEASE", 
> > or "LATEST_PEER_REVIEWED".
> 
> Files have properties, but those are versioned.
> 
> The only unversioned stuff we have are properties on revisions
> themselves.  But I don't see how that will help you.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org