On Fri, Mar 12, 2004 at 04:40:44PM -0500, Rob van Oostrum wrote:
> That depends. In cases where you want to integrate with the current mainline
> of development but don't necessarily want to expose one set of changes to
> another set of changes (in cases where 2 changesets have files in common),
> using a single integration sandbox will not work. In my particular case,
> various sets of changes go into various discrete channels of QA ("will
> change A work without change B" and "how about we pull change X out of this
> release" are daily occurrences). So I am very serious about keeping
> everything nice and separate. Hence the purpose-built integration branch
> model. Only relatively trivial changes - the ones that go on and off my
> radar quickly and are unlikely to cause problems - are made directly in the
> maintenance branch. In terms of volume, the latter represents the majority
> of work. In this particular case, the single release point is the
> maintenance branch which is the seed point of most private branches. Since
> it is also where most of the work is taking place, it's not always desirable
> to do integration there.
>
> In short, I want to control a singular sequence of release, while
> safeguarding my ability to change everything around if a client should so
> desire.
Okay - this is good to know. In addition to the two kinds of
contexts I mentioned before, perhaps an even more fundamentally
important issue is that of a particular set of development+SCM
"values". By that I mean the following (in a nutshell) regarding
a shop's view of its development changes and their integration:
* Do you need to emphasize and value "the whole"
over "the sum of its parts" ?
OR
* Do you need "the whole" to be EXACTLY "the sum of its parts"
The issues/principles involved are those of:
- consistency
- correctness
- completeness
- coherence
- identifiability
- reproducibility
- separability
- selectability
- and "safety versus liveness"
The "continuous" integration/update approach values the whole
over the sum of its parts. With suitable tools, it can preserve
and maintain all of the above EXCEPT separability+selectability,
and prefers liveness and completeness (wholeness) as a stronger
value, and being able to have a running, working, integrated
whole as soon and as frequent as possible. But you lose the ability
to easily separate and select changes in a plug-and-play fashion
to combine and configure "feature-sets" as easily as you would
perform algebraic operations on disjoint sets.
The "whole MUST EQUAL the sum of its parts" approach
needs to place more value on the ability to algebraically
add/subtract and reconfigure changes and groups of changes
at integrate/build/compile-time (as opposed to run-time or
deployment-time for example) and fine-grained integration
(both to and from the codeline) breaks that. You can still
identify and reproduce distinct changes but you cannot separate
them and select them for individual reuse outside the context
of the other things you integrated them together with (they
are inextricably intertwined - yet still identifiable and
reproducible).
Some tools like SABLIME and TrueChange (formerly ADC), and
I think possibly even VestaSys (not sure) are based on this
latter more algebraic model. (Also see Andreas Zeller's
PhD. thesis on "Configuration Management with Version Sets"
at <http://www.infosun.fmi.uni-passau.de/st/papers/zeller-phd/>
(also see <http://www.infosun.fmi.uni-passau.de/st/papers/>
for a list of other papers)
So you are spot-on that, in an environment where your
configuration management plan must have separability
and selectability, that the "continuous emergent wholeness"
approach will break your back. I like to be able to handle such
issues on a business-case basis and have the configurability be
at run-time or deployment time (with product-line architectures
employing component-based and service-oriented strategies)
but fully understand it is not always feasible, and that the
initial investment in architecture to do it isn't always well
aligned with the current business model.
> The trick as it turns out is to just tag everything I
> do. Always tag the point from which to merge, the point just
> before the commit of merge changes and the point immediately
> after. On average, I do about a half-dozen releases a day
> like this, and there are very rarely any merge conflicts of
> any significance. For larger changesets that span more time,
> there are the merge conflicts. Whether you choose to deal
> with this pain in small bits or all at once depends entirely
> on the circumstances. I don't think that either option is
> right or wrong. It all depends.
I guess I had the impression that this was happening for
me automatically with SVN by virtue of its change-sets and
repository-wide versioning (tho with a numeric rather than
symbolic identifier). What am I missing about how change-sets
work in SVN and how they can be referred to (even when the
branch they might have been created in may be obsoleted/removed)?
> I really appreciate this meeting of minds Brad.
Yes - me too!
> Have your book on my desk so I must think you're doing
> something right ;-)
Cool! ;-)
--
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 Sat Mar 13 01:25:35 2004