On Tue, Sep 28, 2004 at 11:05:38AM -0700, Tom Mornini wrote:
> Just for my curiosity, do you feel this way about every other
> versioning system out there that allows modifications to tags?
Most of the versioning tools I know have a way of creating a
a named configuration that corresponds to a set of revisions
of a set of things.
Once The tool lets me create a named configuration, it
typically lets me either explicitly change its definition,
or explicitly "lock" it. It typically does /not/ let me
indirectly/implicitly change the definition of a named
configuration via a checkin or commit command.
> > But I think separate from that, for some at least, isn't
> > whether or not the thing is changeable; it is whether or
> > not the thing "rightfully" belongs (and should be viewed
> > together with) the other set of things in will show-up
> > with.
>
> Show up where?
In the hierarchical versioning namespace of branches
their named revisions.
> For heaven's sake, people have been using "copy and move
> aside" for version control since the advent of electronic
> storage!
They've been doing that for representing releases or released
versions. They weren't doing that for every developmental
configuration - even tho they still wanted/needed/used ways
of defining named developmental configurations.
> Sorry, Brad, just cannot agree with you here. I think it's just
> about people's inflexibility in adopting to new ideas.
Interesting. To me, given the way Subversion does it - I'm
seeing people who say they are open to that and like that.
just that it isn't always the right match for their need
and use. Some others are saying that just one of those
ways is both necessary and sufficient.
One group is saying "one size fits all and is all you need"
and the other is being open to other view co-existing with
the current one.
> Question: How else could one represent it with the complete
> context provided by current implementations?
If we fall back upon a few basic CM terms/concepts, I think
we can get at the crux of the issue before making any
implementation assumptions.
Lets start with the notion of a CONFIGURATION. I'll
boldly suggest it is the most basic/primitive/fundamental
notion of CM (indeed, it is the 'C' in 'CM' :-)
The basic concepts term I believe are relevant to this
discussion are:
* configuration
* named configuration
* baseline (baselined configuration)
* current configuration
For the sake of simplicity, lets say a "configuration"
is the set of elements and their corresponding revisions
necessary to (re)produce some delivered "item". It has
some identifier (or identification mechanism).
Not every configuration needs to have a name associated
with it. I think we all agree it is often useful, and
even necessary to do at times. So once we have the
ability to create a configuration, the ability to
name it (thus creating a "named configuration") is
the logical and necessary "next step".
From there we have the notion of a "baseline" (a.k.a.
a "baselined configuration"), and a "current configuration".
A baseline is essentially a "configuration" that has
been formally blessed and frozen, so that it may be used
as a basis for requesting and making subsequent changes.
Each change against a baseline creates a new "current
configuration" which is defined as "the latest baseline"
PLUS "the latest approved set of changes".
So each change creates a new configuration (which
we may or may not choose to also give a name), and
"current configuration" is a dynamic concept. It isn't a
configuration so much as a "reference" to the configuration
that is "current": When a new configuration becomes
"current", the reference changes from referencing the
previous configuration to now referencing the newest one.
I will claim that Subversion's notion of a "copy" maps to
the CM concept of "current configuration". The set of
elements+versions of a "copy" is the "current configuration"
(for a particular branch, where the name of the copy represents
the name of the branch :-)
Subversion's notion of a given "fixed" configuration is a
"global revision number". It doesn't quite fully support
the concept of an arbitrary fixed configuration because
it doesn't (yet :-) allow us to assign the name of the
configuration (we have to use the revno, which we don't
get to choose)
Subversion's notion of a "baseline" would be a "copy"
that is frozen against further updating/evolution.
Granted, if one is going to use only one conceptual
representation to accomplish all of "configuration",
"baselined configuration", and "current configuration"
all in one mechanism, perhaps Subversion's "copy"
mechanism is indeed the happiest middle-ground.
However I will contend that its not the simplest or
cleanest in concept or in logic. I think the simplest
and cleanest is to have the "configuration" be the
basic building block. And for "baselined configuration",
"current configuration", and "branch" (or "variant")
to all be things which build upon the basic primitive
of "configuration" in a simple, unifying way that lets
each exist independently while all being conceptually
aligned.
And I agree that the notion of a versioned filesystem
is a clean and simple representation for viewing and
navigating it. And I think that versioned filesystem can
be even cleaner and simpler while supporting the basic
notion of "configuration" and the various forms of it,
without trying to make the same mechanism do them all. The
same base mechanism can support them all without trying to
"be all in one".
--
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 Wed Sep 29 05:36:48 2004