You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Nicolás Lichtmaier <ni...@reloco.com.ar> on 2004/03/31 21:21:26 UTC
Subversion and "Configuration Management"
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".
I've thought of keeping a separate DB with this tuple: (repo-path, rev,
label).
Am I missing some existing solution to this problem?
Thanks for you help!
Bye!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Jim Correia <ji...@pobox.com>.
On Mar 31, 2004, at 4:35 PM, 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.
I asked a similar question. Answer here [1] if it helps.
[1]
<http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=6370>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Ben Collins-Sussman <su...@collab.net>.
On Wed, 2004-03-31 at 15:38, Nicolás Lichtmaier wrote:
> Do you think it would be hard for a newbie (like me) to add this
> functionality to subversion? Perhaps adding a new table to the db...
I don't know how hard it would be for you to code this, but I think it
might be hard for you to persuade all the developers to redesign our
repository schema. :-)
Seriously, the feature you want makes sense for a system like CVS, which
is heavily focused on per-file versioning. Every file has its own RCS
file, and the RCS file format does exactly what you're talking about:
it allows you to attach unversioned labels to specific file revisions.
SVN doesn't even (yet) expose per-file revisions to the user! It's
built in a completely different way. Your feature would require a
*massive* redesign.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>>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.
>
>
Do you think it would be hard for a newbie (like me) to add this
functionality to subversion? Perhaps adding a new table to the db...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Brad Appleton <br...@bradapp.net>.
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 <br...@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
Re: Subversion and "Configuration Management"
Posted by Brad Appleton <br...@bradapp.net>.
On Fri, Apr 02, 2004 at 01:39:21AM -0300, Nicol?s Lichtmaier wrote:
> I've talked to the paerson in charge of CMM, andhe told me the
> issue is not just code, but documentation.
So, were you planning on versioning your docs in subversion?
> And not only these kind of tags, but also lots of per-file
> non-moveable tags like "DRAFT-A", which would work like a stamp/seal.
> And the key part of this is "per file".
I think we are letting the "per-file" assumption get the better of us.
I don't think the requirement is per-file. I think the requirement is
per "item" where an item is something that you need to "baseline".
In the case of your code, the "item" that you baseline is the stuff
that was used to make the build that was blessed as acceptable.
In the case of documentation, I think your "item" is the document
itself, and the complete document needs to get "baselined" (but the
document might actually be broken-down into several files, and you
have to change several of them for a given change - in which case
you still have a "document" change task, and the promotion-branching
approach still works BUT you need a separate set of promotion branches
per baselined "item".
I don't think you require file-level promotion, that is just one
implementation that I suspect someone became so accustomed to,
that they came to think that promotion itself is a file-level
concept. But if we go back to basic CM fundamentals, it really
isn't laid out that way. What's laid out is the need to have
approval promotion cycles for each configuration item of a
configuration.
It may often be the case that "a document" maps to one file
for you. I do know of many cases where this is not always so,
particularly with larger documents in Word or Frame or XML
that are composed of several smaller "chapter-level" files
in an overall book, and with markup languages where a
document is quite literally "built" by processing multiple
files and then collating and assembling those results into
a single "publishable" document (possibly even generated as PDF).
I think if you separated documentation change-tasks from code
change-tasks that would solve part of your problem. And if your
documents need a different promotion-cycle than your code, you
could use separate promotion-branches for your doc-change-tasks
(but still the same resultant "mainline" branch at the very end
of the cycle). Thats solves another part of your problem.
Plus, if you need to treat different groupings/sets of things
like different "components", I believe subversion has a way to
do that (probably more than one). If worse came to worse, you
could use a Property on every file to indicate the "component"
(or document) it belongs to, and then between that, and the
different sets of promotion branches per type-of-item, you
could in fact correlate (and query/compute) the promotion
level for each item Configuration Item.
If you still think you must classify and promote individual
files (even docs) in order to meet your requirements, I would be
very interested in hearing more details as to WHY it absolutely
has to be at the individual file level. I run into that a lot in
my experience and it usually turns out to not be the case, and
the constraint was mentally imposed by ones own prior experience
and simply not having had opportunity to become familiar with
other implementations to meet the promotion modeling requirements.
--
Brad Appleton <br...@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
Re: Subversion and "Configuration Management"
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
I've read your interesting message about using brnahces to signify "code
states". I've talked to the paerson in charge of CMM, andhe told me the
issue is not just code, but documentation. And not only these kind of
tags, but also lots of per-file non-moveable tags like "DRAFT-A", which
would work like a stamp/seal. And the key part of this is "per file".
When you talk about code is true that you'd better considere the set of
changes as a whole. But we seem to have the need to classify and order
individual files, and put labels to them. I don't see how Subversion
could help us here. =( In fact it's very probable we end up not using
subversion because of this very problem.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Brad Appleton <br...@bradapp.net>.
On Thu, Apr 01, 2004 at 04:45:43PM -0500, Gary Feldman wrote:
> ----- Original Message -----
> From: "Brad Appleton" <br...@bradapp.net>
> ... excellent write-up on a way to do promotion elided
> > 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.
>
> Given this model, how would one determine the current state of a given task?
> If I'm following this correctly, the only set of information that
> corresponds to the task is the original task branch. Would one have to
> query the property name on each of the state branches?
Very good question! At first glance, I was thinking as you did
that I would have to query against all the branches. Then I
thought of another possibility - but it would require additional
tooling/scripting ...
When a change-task is ported from branch to branch, the
ChangeTask property is associated with the revision committed to
that promotion branch. If this were automated by a "promotion"
script, then at the same time, the script could also "bump
up" the PromotionLevel attribute of the last global revision
associated with the task-branch named after that ChangeTask
So to answer the question:
- what tasks have been promoted to this level?
-- you would query (svn log) the corresponding promotion branch
looking at the ChangeTask Property
- what is the promotion level of this task?
-- you would query the LATEST on the Task branch
looking at the PromotionLevel property
I'm not an SVN expert - so I'm not positive about all this -
but I think it could work.
Note: this means you would have to keep those task-branches around
(some like to delete them after committing them).
--
Brad Appleton <br...@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
Re: Subversion and "Configuration Management"
Posted by Gary Feldman <ga...@memento-inc.com>.
----- Original Message -----
From: "Brad Appleton" <br...@bradapp.net>
... excellent write-up on a way to do promotion elided
> 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.
Given this model, how would one determine the current state of a given task?
If I'm following this correctly, the only set of information that
corresponds to the task is the original task branch. Would one have to
query the property name on each of the state branches?
Gary
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Subversion and "Configuration Management"
Posted by Brad Appleton <br...@bradapp.net>.
[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 <br...@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
Re: Subversion and "Configuration Management"
Posted by Ben Collins-Sussman <su...@collab.net>.
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org