Karan, Cem (Civ, ARL/CISD) wrote:
>> Are you currently using multiple related projects/products in the
>> same repository? (where each product has its own release labels,
>> and may also depend on certain release versions of other products?)
>>
>
>
> Yes, which is why I want the whole repo-wide version numbering
> system. Invariably, someone adds a new feature (or breaks an
> old one) that causes the whole project to start failing
> regression tests, and I need to be able to roll everything
> back easily.
Wouldnt this be a two-edged sword? I would think there are often time
when you need to rollback just the one component, not the whole repo.
>> The problem arises when you have a bunch related projects/products,
>> or you have a set of "components" and you make multiple
>> products/projects form those components. Each product has its own
>> releases and uses a subset of "common" components as well as 1 or
>> more components specific to that project. So release-numbers need
>> to be tracked that are specific to each particular product, to the
>> "core/common" set of components, and to the entire product-line as
>> a whole.
[...]
> I see your point, as that is exactly the sort of thing that is going
> on; we have a core set of utility 'libraries' which, if broken, cause
> all the other projects to go haywire. The problem is that if you
> have a per-group revision number, you need to be able to have other
> groups be aware that they are working against a group.
Yes. I would think they have to be aware of this even if they dont have
a per-group revision number, because the revision of a component being
used by the group that is developing it is likely to be different from
the rev referred to by others that need it so they can build.
I.e., if I
> have groups A, B, and C, when I commit a revision of group A that
> depends on B and C, I need to able to state that A depends on B::234
> and C::38, and have that built into the commit command. If you don't
> do this, then it becomes more of a problem then a solution.
That's the part I think one ends up having to do anyway (even with
repo-wide revisions).
ClearCase/UCM has an interesting notion of "Composite Baselines". It's
like a "Label of Labels" (or "Tag of Tags") where the "Composite" Tag is
really a reference to the other tags that make up the whole "assembly".
It gets even more interesting when you have the notion of "LATEST" (or a
dynamic/floating tag). so if I had a composite "LATEST_SYSTEM_BUILD" tag
that consisted of "LATEST_COMPONENT1_BUILD" and
"LATEST_COMPONENT2_BUILD" - then when I "promote" a components flaoting
label to the new latest component build, the "composite" tag picks up
the new stuff :-)
> As it stands, by putting it all into one repository (and keeping
> track of the revision number that last worked for me) I can always
> see where things broke. If you want to make it so that I can roll
> back a group of files (E.g., 'svn merge -r B::head:B::234') or update
> to an older set of files (E.g., 'svn up -r B::234') or make it so
> that updates/commits/etc. are per-group dependent, then I can see
> where you are going.
Supposing a "branch" were associated with a "root" directory that its
versions/versioning applied to. By default, it is the repository "root"
and is "repo-wide" (or perhaps by default, it is the same as the parent
it branched from, and if it didnt have a parent it defaults to repo-wide).
I could have a "system" branch, a branch for "component1" and another
branch for "component2". When I "commit" to "componentN", it creates a
component-specific revnum. And when I merge from componentN branch to
the system branch, it makes a repo-wide version number. (NOTE that I can
do this regardless of whether or not I have repo-wide versioning and
that its a somewhat common approach to take).
If I had the ability to make those other branches and their revnums be
truly component-specific, it means that a "merge" could be aware of the
difference between "assembly" integration (which would simply include or
reference the version of a set of files not already included in the
file-set) and "merge" integration where I actually had to merge (or at
least copymerge) contents.
It also means a "component-specific tag" would possibly have to know
it's "Context". When it created a new component-specific revno, it would
have to already know the current revno of not only itself, but of its
parent-branch (which it would use to know which versions of files not in
this component could be visible in the working copy)
This isnt all that different from file-system semantics, and having
"version aware" svn "externals", such that when you define a component
directory ro subcomponent directory in your repository structure, you
are defining a version-context relationship (e.g., new versions of
subcomponent "ABC" are always in the context of the currently visible
version of parent component "AB")
--
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 Fri Aug 5 09:04:31 2005