On 11/14/07, schellin@xs4all.nl <schellin@xs4all.nl> wrote:
[...]
> Well, it does happen (suites usually do not provide best-in-class tools,
> so if you want best-in-class, you have to mix and match).
>
> An additional reason for this is that we have a development process that
> requires code review before commits, and these reviews are done using a
> tracking system. Therefore, we encounter 2 different IDs in every commit.
I can certainly understand this as we also have multiple tracking
systems, however, I think your organism needs to seriously re-engineer
its processes.
If you really want/need to put multiple tracking numbers in your SVN
log entries, the pre-commit hook plus the "tsvn:logtemplate" can help
you do this. Just include places in your template for the various
tracking numbers, then your pre-commit hook can parse the log entry to
extract and validate the numbers.
Having said that, here is how my organisation handles this:
As I said, we do have multiple tracking systems, but only one of those
has any direct connection to the software development. (It is a "home
grown" MS Access application we are stuck with.) Our software commits
only need a single tracking number associated.
The software tracking system is fed by 3 other tracking systems and
feeds yet another tracking system (which can also feed the software
tracking):
Requirements tracking is done with something called "DOORS". When
requirements are changed, one or more new software "tickets" are
created, which refer to the relevant identifiers in requirements
tracking. These RQ-IDs are contained in the software issue (SWI), not
the software nor SVN. Only the SWI tracking number is logged in SVN.
Customer issues are tracked with something else that I do not know
what it is called. Customer issues can feed both software, directly,
and the requirements.
Any software issues driven by customer issues refer to the CI by
number in the SWI.
Likewise, issues from the testing group are tracked by TIR. If a
software change is needed to resolve a TIR issue, then a SWI ticket is
created and, again, only the SWI refers to the TIR issue.
For code reviews, the SWI tracker feeds the Software Quality Assurence
System (another home grown MS Access application). If the SQA process
finds a problem, it can either force the associated SWI to the
re-analyse state or generate a new SWI.
In summary, the associations between issues in the various tracking
systems are handled by the tracking systems, not the software
versioning system.
Any (official) documents we need to see for a given asoftware change,
we just follow one link from the SVN log to the associate SWI, which
will include any links to issues/documents in the other systems.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Nov 15 00:29:25 2007