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 <brad@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 <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 Thu Jan 13 20:59:21 2005