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 20:43:46 2005