[redirecting here since conversation seems to have
migrated from users to dev]
On Fri, Apr 02, 2004 at 01:39:21AM -0300, Nicol?s Lichtmaier wrote:
> I've read your interesting message about using brnahces to
> signify "code states".
> [ in
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=9075
> and
http://subversion.tigris.org/servlets/ReadMsg?list=users&msgNo=9147
> ]
>
> I've talked to the paerson in charge of CMM, andhe told me
> the issue is not just code, but documentation. And not only
> these kind of tags, but also lots of per-file non-moveable
> tags like "DRAFT-A", which would work like a stamp/seal. And
> the key part of this is "per file". When you talk about code
> is true that you'd better considere the set of changes as a
> whole. But we seem to have the need to classify and order
> individual files, and put labels to them. I don't see how
> Subversion could help us here. =( In fact it's very probable
> we end up not using subversion because of this very problem.
I think we are letting the "per-file" assumption get the better of us.
I don't think the requirement is per-file. I think the requirement is
per "item" where an item is something that you need to "baseline".
In the case of your code, the "item" that you baseline is the stuff
that was used to make the build that was blessed as acceptable.
In the case of documentation, I think your "item" is the document
itself, and the complete document needs to get "baselined" (but the
document might actually be broken-down into several files, and you
have to change several of them for a given change - in which case
you still have a "document" change task, and the promotion-branching
approach still works BUT you need a separate set of promotion branches
per baselined "item".
I don't think you require file-level promotion, that is just one
implementation that I suspect someone became so accustomed to,
that they came to think that promotion itself is a file-level
concept. But if we go back to basic CM fundamentals, it really
isn't laid out that way. What's laid out is the need to have
approval promotion cycles for each configuration item of a
configuration.
It may often be the case that "a document" maps to one file
for you. I do know of many cases where this is not always so,
particularly with larger documents in Word or Frame or XML
that are composed of several smaller "chapter-level" files
in an overall book, and with markup languages where a
document is quite literally "built" by processing multiple
files and then collating and assembling those results into
a single "publishable" document (possibly even generated as PDF).
I think if you separated documentation change-tasks from code
change-tasks that would solve part of your problem. And if your
documents need a different promotion-cycle than your code, you
could use separate promotion-branches for your doc-change-tasks
(but still the same resultant "mainline" branch at the very end
of the cycle). Thats solves another part of your problem.
Plus, if you need to treat different groupings/sets of things
like different "components", I believe subversion has a way to
do that (probably more than one). If worse came to worse, you
could use a Property on every file to indicate the "component"
(or document) it belongs to, and then between that, and the
different sets of promotion branches per type-of-item, you
could in fact correlate (and query/compute) the promotion
level for each item Configuration Item.
If you still think you must classify and promote individual
files (even docs) in order to meet your requirements, I would be
very interested in hearing more details as to WHY it absolutely
has to be at the individual file level. I run into that a lot in
my experience and it usually turns out to not be the case, and
the constraint was mentally imposed by ones own prior experience
and simply not having had opportunity to become familiar with
other implementations to meet the promotion modeling requirements.
--
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: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Apr 3 02:01:46 2004