You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Stephen McConnell <mc...@yahoo.com> on 2005/01/13 14:06:07 UTC
Integration Builds and Tags
Alright, maybe I'm still stuck in the old CVS mentality. I was able to
do this under CVS, but the Suggestions I got in the topic Moving Tags
are not working...
I have to be able to keep track of Three types of builds
Development
Test
Production
Development is set up under "trunk"
I tagged the initial level of "trunk" as
test and as production.
Now, someone has checked in a modification to files in the trunk tag
and I need to move it to the "test" tag. When I try to "TAG" the
changed files for "test", it tells me that the file already exists in
"test".
When I used to "tag" something in CVS for "test", it would put a tag of
"test" on it and I could do an extraction of the files tagged as
"development" and it would be there AND I could also do an extraction
of "test" and it would be there.
How do I do this in Subversion.... or can I do this?
Stephen McConnell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Integration Builds and Tags
Posted by Brad Appleton <br...@bradapp.net>.
On Thu, Jan 13, 2005 at 05:21:38PM +0100, Peter Valdemar M?rch wrote:
> When I used CVS we also used "moving tags" to indicate things like
> "Integration Tested", or "Current Daily Build" or things like that...
I've used this notion of a "rolling label/tag" in several
tools as well. Its really a dynamic marker/reference to
the "latest <status-level> version"
> Using branches and merging between them is kindof painful especially if
> it is to be done from a script. Especially because the script needs to
> keep track of merge history to avoid repeated merges.
Uggh! I forget that SVN doesn't do smart merging yet. That
would be another definite "downer" for using promotion branches
and point for using the property-based or rolling-tag approaches.
Another thing to consider ... The promotion-property mechanism and
the promotion-branch mechanism both allow all previous (no longer
latest) versions of a given promotion-status to remain on the
codeline and be easily queried if you ever need to answer the
question: what was the 'current TEST' version contents 3 months
and 3 days ago.
The rolling-tag ("current" configuration marker for a promotion-level)
may not necessarily preserve that information (or if it does, it may
be a lot more work to get at it -- which may not matter to you if
you don't think you need it all that often). I don't know enough about
the implementation details to know which is the case for SVN.
> I personally think that moving or "rolling" tags has merrit.
> Especially if the tags change often, and no work has to be
> done "inside" them.
>
> (I've just seen that Mr. Appleton has answered here too.
> Well, OK, differing opinions are fine, I guess... ;-D)
Most definitely!
FWIW - I wasn't trying to recommend one particular approach over
another so much as identify the different alternatives and the
tradeoffs involved. Since Steve was trying to 'rolling tag'
approach I wanted to bring up the other two (Ben had already
mentioned the promotion branch).
Another interesting question is, which of them seems like
a better "fit" with the difference between the SVN paradigm
and the CVS paradigm. I sort of like the fact that the property
approach doesn't have to create any copies (branches or tags),
just associate a status-attribute with an existing revno.
However, readily accessing it is somewhat less convenient
than via a "copy", plus its probably desirable to have a
copy anyway for the "latest" of each status-type.
--
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: Integration Builds and Tags
Posted by Peter Valdemar Mørch <no...@morch.com>.
Ben Collins-Sussman wrote:
> Honestly, if the tag keeps changing all the time, then it's not really
> much of a tag, is it? It's more of a branch.
>
> It sounds like Stephen should be using 3 branches and porting changes
> between them. Then when he needs to make a 1-time snapshot (i.e. to
> remember something that got delivered to a customer), he can copy the
> production branch to a tag.
Hmm... I guess this could go several ways.
When I used CVS we also used "moving tags" to indicate things like
"Integration Tested", or "Current Daily Build" or things like that...
Using branches and merging between them is kindof painful especially if
it is to be done from a script. Especially because the script needs to
keep track of merge history to avoid repeated merges.
Also, whereas removing and recreating a tag is a constant-time and
constant-size operation, merging changes from trunk to a branch can
possibly explode the repository size, if the changes are large, and
there are several of such tags, right?
In fact, we currently have a $repos/tags/merge directory as a sort of
poor-man's solution to the repeated merge problem. Here we keep tags
indicating exactly what version of e.g. maintenance branch
$repos/branches/RELEASE_X is fully merged to trunk. So
$repos/tags/merge/RELEASE_X.to.trunk holds exactly this merge history,
instead of requiring some sort of comment convention. (And then we later
use "svn log -v --stop-on-copy $repos/tags/merge/RELEASE_X.to.trunk" to
find the version of RELEASE_X that has been fully merged. This is
automated by svnbranchroot:
http://svn.sunbase.org/repos/svnutils/trunk/src/svnbranchroot
Then we know that
# svn merge -r \
`svnbranchroot $repos/tags/merge/RELEASE_X.to.trunk`:HEAD \
$repos/tags/merge/RELEASE_X.to.trunk \
trunkWC
is what potentially (!) needs to be merged next.
I personally think that moving or "rolling" tags has merrit. Especially
if the tags change often, and no work has to be done "inside" them.
(I've just seen that Mr. Appleton has answered here too. Well, OK,
differing opinions are fine, I guess... ;-D)
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Integration Builds and Tags
Posted by Brad Appleton <br...@bradapp.net>.
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 <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: Integration Builds and Tags
Posted by Stephen McConnell <mc...@yahoo.com>.
I'm sorry to be a pain. I guess it's that I've been a CVS user for so
many years; and I'm stuck in the CVS paradigm.
It often takes a two-by-four to get one to think out of the old box.
I'm going to have to "rethink" the SCM model that I'm used to... in
light of what I have heard.
I've been trying to use some of the Patterns found in Brad's book:
"Software Configuration Management"... I guess I need to give that book
a hard re-read.
Stephen McConnell
--- Mark Phippard <Ma...@softlanding.com> wrote:
> Stephen McConnell <mc...@yahoo.com> wrote on 01/13/2005
> 02:56:49 PM:
>
> > I appreciate the article...
> >
> > None of what anyone has said seems to help, though... there is a
> lot of
> > abstract stuff, but I have been given the responsibility of
> > implementing one of the most hairbrained configuration management
> > systems I've ever seen. They want to be all things to everyone.
>
> You mentioned that developers tell you about specific items to
> "promote".
> If that is the case, couldn't they just tell you specific revision
> numbers? Then you could use standard branches for your "areas" and
> use
> the relatively easy technique of merging specific revisions to a
> branch.
> This is essentially how Subversion handles their point releases.
> Specific
> revisions are nominated for backport, and if approved they are merged
> and
> integrated with the branch.
>
> It is fairly labor intensive, but it seems to match the model you
> described.
>
> Mark
>
>
>
_____________________________________________________________________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security
> Management Services powered by MessageLabs.
>
_____________________________________________________________________________
>
=====
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Integration Builds and Tags
Posted by Mark Phippard <Ma...@softlanding.com>.
Stephen McConnell <mc...@yahoo.com> wrote on 01/13/2005
02:56:49 PM:
> I appreciate the article...
>
> None of what anyone has said seems to help, though... there is a lot of
> abstract stuff, but I have been given the responsibility of
> implementing one of the most hairbrained configuration management
> systems I've ever seen. They want to be all things to everyone.
You mentioned that developers tell you about specific items to "promote".
If that is the case, couldn't they just tell you specific revision
numbers? Then you could use standard branches for your "areas" and use
the relatively easy technique of merging specific revisions to a branch.
This is essentially how Subversion handles their point releases. Specific
revisions are nominated for backport, and if approved they are merged and
integrated with the branch.
It is fairly labor intensive, but it seems to match the model you
described.
Mark
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Integration Builds and Tags
Posted by Stephen McConnell <mc...@yahoo.com>.
I appreciate the article...
None of what anyone has said seems to help, though... there is a lot of
abstract stuff, but I have been given the responsibility of
implementing one of the most hairbrained configuration management
systems I've ever seen. They want to be all things to everyone.
We are using Eclipse (we are also using subclipse and Tortoise). We
create the project structure and use Ant to build an EAR that is
deployed. Fixes to classes are commited to trunk and I need to promote
them to a Test or Production enviornment and do an integratino build.
If I create a new branch or tag each time I promote a class to another
level, then I am stuck creating a new project, checking out the new tag
or branch into the project... Then configuring Eclipse and Ant to do
the build.... building the EAR and deploying it to the client.
If I use the promotion-property model then I don't see how I can get my
"test" project linked to just those revisions that have the
INTEGRATION_LEVEL property set to "test".
Subversion seems to be optimally designed for tagging the ENTIRE
project. And when you are doing bugfixes and moving them to a test
environemnt, that's just not feasable.
I think it seems that best way to manage this is to create a
promotion-branch model. Then, remove the files (classes) from the test
branch or tag and "copy" the new revision in. A two step process...
Unless there is a tool to do this. I was thinking about writing a Java
tool to do this... That's my next step to research... Unless you'all
can give me a more concrete description of how to solve my problem in
Subversion.
Remember.... I did not choose the development cycle model and I didn't
choose Subversion as the solution.... I just got handed it and told
"make it work...." (I love management).
Stephen McConnell
--- Brad Appleton <br...@bradapp.net> wrote:
> Hi Ben & Steve!
>
> On Thu, Jan 13, 2005 at 09:44:51AM -0600, Ben Collins-Sussman wrote:
> > Stephen McConnell wrote:
> > > How do I do this in Subversion.... or can I do this?
> > > I have to be able to keep track of Three types of builds
> > >
> > > Development
> > > Test
> > > Production
> >
> > Honestly, if the tag keeps changing all the time, then it's not
> really
> > much of a tag, is it? It's more of a branch.
> >
> > It sounds like Stephen should be using 3 branches and porting
> changes
> > between them. Then when he needs to make a 1-time snapshot (i.e.
> to
> > remember something that got delivered to a customer), he can copy
> the
> > production branch to a tag.
>
> I was thinking the same thing.
>
> Basically this is a case of trying to implement a
> particular promotion lifecycle model. CVS' tagging
> mechanism lent itself to an attribute-based promotion
> mechanism using tags to indicate promotion-status of a
> version. That's because CVS tags could be used as 'boolean'
> attributes as well as like version-labels. Subversion
> copies are different.
>
> So with SVN, Steve could do what he wanted using properties
> if he liked with a property name of something like "Status"
> or Build-Status (or the more boring "Promotion-Level") and
> property-values of {Development, Test, Production}. The
> downside here is that it might be a bit more effort
> to determine what is the LATEST build with a given
> promotion-status (would have to query the branch for the
> latest revno with a given promotion status).
>
> Or he could use promotion branches with a branch for each
> promotion-level. using promotion branches is a bit easier
> to set-up. The downside is that you have to do copymerging
> to propagate promoted builds between promotion branches.
>
> For more info on several different mechanisms for
> implementing promotion models and their various tradeoffs,
> take a look at the following paper:
> "Agile Build Promotion: Navigating the Ocean of Promotion Notions"
> <http://www.cmcrossroads.com/article/32900>
>
> Hope that helps!
> --
> 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: Integration Builds and Tags
Posted by Brad Appleton <br...@bradapp.net>.
Hi Ben & Steve!
On Thu, Jan 13, 2005 at 09:44:51AM -0600, Ben Collins-Sussman wrote:
> Stephen McConnell wrote:
> > How do I do this in Subversion.... or can I do this?
> > I have to be able to keep track of Three types of builds
> >
> > Development
> > Test
> > Production
>
> Honestly, if the tag keeps changing all the time, then it's not really
> much of a tag, is it? It's more of a branch.
>
> It sounds like Stephen should be using 3 branches and porting changes
> between them. Then when he needs to make a 1-time snapshot (i.e. to
> remember something that got delivered to a customer), he can copy the
> production branch to a tag.
I was thinking the same thing.
Basically this is a case of trying to implement a
particular promotion lifecycle model. CVS' tagging
mechanism lent itself to an attribute-based promotion
mechanism using tags to indicate promotion-status of a
version. That's because CVS tags could be used as 'boolean'
attributes as well as like version-labels. Subversion
copies are different.
So with SVN, Steve could do what he wanted using properties
if he liked with a property name of something like "Status"
or Build-Status (or the more boring "Promotion-Level") and
property-values of {Development, Test, Production}. The
downside here is that it might be a bit more effort
to determine what is the LATEST build with a given
promotion-status (would have to query the branch for the
latest revno with a given promotion status).
Or he could use promotion branches with a branch for each
promotion-level. using promotion branches is a bit easier
to set-up. The downside is that you have to do copymerging
to propagate promoted builds between promotion branches.
For more info on several different mechanisms for
implementing promotion models and their various tradeoffs,
take a look at the following paper:
"Agile Build Promotion: Navigating the Ocean of Promotion Notions"
<http://www.cmcrossroads.com/article/32900>
Hope that helps!
--
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: Integration Builds and Tags
Posted by Ben Collins-Sussman <su...@collab.net>.
On Jan 13, 2005, at 9:32 AM, Peter Valdemar Mørch wrote:
> Hi there, Stephen,
>
> Stephen McConnell wrote:
>> How do I do this in Subversion.... or can I do this?
>
> What you need to do is remove the tag first. Something like:
>
> # svn rm -m "Removing test tag before moving" \
> http://server/repos/tags/tag
> # svn cp -m "Re-creating test tag before moving" \
> http://server/repos/trunk http://server/repos/tags/tag
>
Honestly, if the tag keeps changing all the time, then it's not really
much of a tag, is it? It's more of a branch.
It sounds like Stephen should be using 3 branches and porting changes
between them. Then when he needs to make a 1-time snapshot (i.e. to
remember something that got delivered to a customer), he can copy the
production branch to a tag.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Integration Builds and Tags
Posted by Peter Valdemar Mørch <no...@morch.com>.
Hi there, Stephen,
Stephen McConnell wrote:
> How do I do this in Subversion.... or can I do this?
What you need to do is remove the tag first. Something like:
# svn rm -m "Removing test tag before moving" \
http://server/repos/tags/tag
# svn cp -m "Re-creating test tag before moving" \
http://server/repos/trunk http://server/repos/tags/tag
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org