I've been emailing you on this list; and didn't realize You were
co-author of the book I've been reading to help figure out all this
Config management process.
Thanks for the suggestions; and the help. I'm enjoying the book.
I've been thinking I need to think out of the old CVS box for this.
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.)
Once commited/merged into trunk they notify the config management team
that it's ready to be promoted.
A daily test build is "tagged" or branched and deployed to the Test
server. Once tested, it can be tagged for production. If it fails,
the developer will be responsible for reverting the trunk back to the
old revision.... and public humiliation will commence.
Oh well... Thanks for your help. Sorry to have created a big
discussion... But I have learned a lot.
Stephen McConnell
--- Brad Appleton <brad@bradapp.net> wrote:
> On Thu, Jan 13, 2005 at 10:13:56AM -0800, Stephen McConnell wrote:
> > Brad, thanks for the article.
> >
> > The problem is even more complex than I stated.
>
> Ooh goody! A *challenge* :)
>
> > We have started with a base codeline. As developers
> > "fix" bugs in the trouble tickets or add functionality
> > to the codeline... those fixes need to be promoted
> > to a "Test" environment.
>
> Do the developers "commit" their changes to the codeline
> prior to having their changes marked as "ready to promote"?
>
> > So, I need some way to differentiate between the code
> > that will move to the "Test" environment. Only those
> > classes that are involved in the change need to be moved
> > to the "Test" environment.
>
> Is this an optimization or is it something the tool can
> figure out for you? Do you need to query the tool to ask
> which files/classes where changed and then try to update
> only those into the test environment? Or is it okay if you
> simply tell the tool to update/merge the resulting rev for
> that change into the test-environment, and the tool will
> (correctly) update ONLY the files that changed?
>
> I'm trying to figure out what is causing you to have to
> identify only those files that changes since the previous
> rev? What you describe sounds like trying to "port" a
> CVS-style promotion mechanism to SVN, which was itself
> "ported" to CVS from the way that PVCS did things out
> of the box. That mechanism was file-version attribute
> based. You had to have a promotion-attribute per file
> version, and you had to known which files were changes.
>
> If changes are moved from development to production in
> EXACTLY the same sequence their were "committed" by
> development, then I think you could just use promotion
> branches, and merge from one promotion branch to the
> next, and repeated merging wouldn't be an issue so
> long as the test-branch was always just an earlier version
> of the base branch evolving in the same order, but perhaps
> a bit slower, and possibly skipping over some dev-versions
> between moves
>
> > BUT, here's the catcher.... We have multiple clients.
> > Once our testers test the "fix", it needs to be moved
> > to a Client QA test. And they ONLY want those fixes
> > applicable to them (unless one fix affects all the
> > clients).
>
> Okay, so is this a case of having multiple variants,
> where not all clients want every available fix at the
> same time? (In which case, you would really need a
> separate branch + test-area PER CLIENT).
>
> Or is this a case of having to maintain only a single
> branch/codeline across all clients, but having to
> keep track of which versions will go to which clients?
>
> (Do you need to track possibly multiple QA promotions,
> one PER CLIENT, all for the same build?)
>
> > I need to move certain code bunches to a Client Test
> > Integration Build.
>
> Here again, it would be good to clarify if you really
> need to move ONLY the files that were changed, or if you
> can refer simply to the codeline-wide revno that resulted
> from committing the change?
>
> > Now, If I use the "properties" idea, then each revision
> > of a file can have only one "state" as defined by the
> > "INTEGRATION-LEVEL" property.
>
> Note that with SVN, revisions are codeline/codebase-wide,
> not per file. A given revision number applies to ALL
> files participating in that codeline. You probably
> don't want to think in terms of moving individual
> files or file-versions with SVN, you want to think
> in terms of moving a particular state of the entire
> codeline, where a given version stores both its
> *content* (only the stuff that was changed) as
> well as its *context* (the stuff that wasn't changed,
> but was still needed to build+test).
> * With CVS or PVCS, you would conceptually think in terms
> of promoting a file-version to a particular status that
> represented a full configuration: the file-revision
> moves-up to meet the state-marker.
>
> * With SVN, its kind of the reverse, you need to think in
> terms of promoting the status of a full configuration:
> you are moving-up the state marker of a configuration.
>
> So its possible part of your struggle is that you may
> still be trying to think in terms of file-based "particles"
> (individual revisions of individual files) instead of
> thinking in terms of component-based/project-wide "waves"
> (repository-wide versions of a project-wide codeline)
>
> > AND A FURTHER KICKER... For the Production Level, the
> > client only wants those classes to be included that they
> > have tested to be moved the "THEIR" production level.
>
> Do we have a difference in granularity-type here? Do
> things get moved from Dev to Test/QA based on what
> classes have been changed, but moved from Test/QA to
> production based on what classes were Tested? Does
> the set of classes that were tested ever not exactly
> match the set of classes that were changed?
>
> > I receive an email with a description of the code the
> > developer wants to "Promote" to Test. I need to promote
> > it, do a build and move an "EAR" file out to the test
> > server for our test team to test. Once it's tested by
> > our testers, I need to move that code the the client
> > test bed.
> >
> > Then, once the client has tested it, I need to move that
> > code to the client production..... for each individual
> > client.
>
> Are the test-areas and the production areas full-fledged
> workspaces using the version control system that you can
> checkin/checkout/merge within? or are they simply file-trees
> external to the version control repository and don't utilize
> any VC tool commands? (In your case, things might be easier
> if they are full-fledged version-control workspaces)
>
>
> --
> 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 22:36:38 2005