It's all about the answers!

Ask a question

Questions from RTC PoT


Gary Mullen-Schultz (28725536) | asked Sep 19 '08, 2:56 p.m.
A few questions from the RTC PoT I just did in Minneapolis.

1. Is there any way to separate artifacts of different types into individual databases? The concern is from a bank, and involves compliance: they don't want a single administrator to have the ability to modify work items, code, change set history, build history, etc. (which they could theoretically do now as a DBA as all the artifacts and metadata are kept in the same database).

2. Is there a way to get an exclusive lock on a resource from the SCM? The example given was a binary file resource (an audio file in this instance) for which merge is not possible. They don't mind the optimistic locking mechanism for source, but would like to be able to occasionally lock other resources.

3. Can I configure, from a security perspective, the information a given role can see? Let's say I don't want certain people to be able to see the details of a work item, only the title - is that possible?

4. Let's say that the customer has a ton of interdependent code in a single source-control repository. Do they need to copy it all down to a local RTC repository? They'd like something similar to ClearCase views, so that some code could remain up on the server.

Thanks in advance for any help answering these questions.

One answer



permanent link
Todd Lainhart (40611) | answered Sep 19 '08, 5:08 p.m.
FORUM MODERATOR / JAZZ DEVELOPER
garymu wrote:
A few questions from the RTC PoT I just did in Minneapolis.

1. Is there any way to separate artifacts of different types into
individual databases? The concern is from a bank, and involves
compliance: they don't want a single administrator to have the
ability to modify work items, code, change set history, build
history, etc. (which they could theoretically do now as a DBA as all
the artifacts and metadata are kept in the same database).


This kind of partitioning and cross-repository references between
artifacts are not possible in this release.

2. Is there a way to get an exclusive lock on a resource from the SCM?
The example given was a binary file resource (an audio file in this
instance) for which merge is not possible. They don't mind the
optimistic locking mechanism for source, but would like to be able to
occasionally lock other resources.


There are no exclusive locking mechanisms in SCM in this release.

3. Can I configure, from a security perspective, the information a
given role can see? Let's say I don't want certain people to be able
to see the details of a work item, only the title - is that possible?


Not in the initial release. Read access for artifacts is available to
all contributors.

4. Let's say that the customer has a ton of interdependent code in a
single source-control repository. Do they need to copy it all down
to a local RTC repository? They'd like something similar to
ClearCase views, so that some code could remain up on the server.


I'm not sure that I completely understand the question, but all
versioned artifacts recognized by Jazz must be in a Jazz repository.
You can choose to selectively load some subset of those artifacts into
your file area. Only when those artifacts are loaded locally can you
navigate the repository namespace via the RTC Package
Explorer/Navigator. But you can navigate the repository versioned
namespace via other views, e.g. drilling down component baselines via
the Repository Files view (launched from the Repository Workspace view).

There isn't a dynamic view mechanism in Jazz like there is in ClearCase,
but there is a somewhat-similar filearea-based view mechanism as in
ClearCase, in the way that I described.

Thanks in advance for any help answering these questions.


Please file enhancement requests for that functionality that you or your
customers think are required.

--
Todd Lainhart
Jazz Repository/Foundation Team

Your answer


Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.