You have to do two things to run BranchManager for DOORS® in french:
You need to configure DOORS to use the BM scripts that are deployed in
another location, most often a network share is used. A registry key needs to be set on the client
PCs, that will make DOORS find the plugin scripts.
So if the IT has the ability to deploy a registry key, our suggestion would
be to put the scripts on a network share and set the addins / projectaddins
configuration in the registry of the client PCs. This way the script can be
updated by just replacing the files on the network share and all clients
will immediately use the new files. If the registry key cannot be deployed
centrally, we can also do that immediately from DOORS. Normally no admin
rights are needed, since the DOORS installation directory does not need to
be changed.
For this the following registry keys need to be added / changed:
HKEY_CURRENT_USER / Software / Telelogic / DOORS / 9.3 / config
with:
addins = <install_path>\menu\EN\addins
projectaddins = <install_path>\menu\EN\projectaddins
If the addins/projectaddins value already exists, then these values need to
be added to the existing value with a semicolon as a separator.
Also, you should add also to one of the path (addins or projectaddins) the source code path. So add another directory to the registry value indicating where to start looking for the code.
For example:
We have fixed node and floating licenses for three different functions:
Two hours since first usage
The default license information (stored in the branch manager tree) is being overridden if users go to license preferences, update and save.
The results then are saved in the user directory .branchmanager location in the preferences.xml.
To revert the update, simply delete the preferences.xml file in the user directory called .branchmanager.
Incomings links are never considered during branching of a module. Incoming links are not data associated with the target module.
This is also the case for comparing and merging.
All the formats supported by DOORS are supported by BranchManager for DOORS.
First, terminology: DOORS links between DOORS objects are stored in linksets (which can be empty).
Linksets
have a list of links (absolute number to absolute number) and have defined a source module (source of the links)
and a target module (target of the links).
Linksets are stored in link modules.
Link pairings are stored in the
source module, and define what link module (and thus the linkset) to use for storage when creating links.
We
can have all kinds of combinations of these three:
BranchManager will now branch empty linksets, i.e. a linkset in a link module that has no links in it.
However, there are some conditions for the copy operation.
An empty linkset will only be branched if:
What that means is, if there is an empty linkset in a link module, and that link module is not "used" during the
branching operation of its source module, then that empty linkset will not be branched.
The reason for this is: it is
impossible to know what link module is storing a linkset for a source module if that linkset is never used to store
a link or never alluded to by a link pairing (unless we scan the ENTIRE database's link modules looking for the
source module).
So BranchManager can find and branch empty linksets, but only if the link module storing the empty
linkset is used by the source module for non-empty linksets or is specified in a link pairing in the source module.
Examples:
When there are objects in your Source Module, that have links into baselines of that Source Module, these links cannot be recreated when branching,
because the baseline information is not available there. Baselines exist only in the Source Module and not in the Branch Module. The links will be created
within the current version of the Branch Module:
You can't copy/paste objects between modules. But you can use Tools > Functions > Copy objects to copy objects between modules.
If you are working in the same database, there is no problem copying objects between modules. The integration script will figure out an object mapping.
But if the modules are splitted, it would be difficult to try to integrate.
Actually, when you restore archived modules, the module will get new unique ids assigned by the DOORS server. This is unusable with modules in their history.
But this does not mean nothing can be done. Here are two use cases:
With branching, there is always a right way to go (assuming a sane linking structure): start at the top of the linking hierarchy and work down.
The top of a linking hierarchy will either have no link targets (because it’s the source that all requirements flow from) or the link targets of the top are in other projects.
After the top is branched, then you branch the next level. The second level's link targets, again assuming a sane linking structure, would be the top level,
and since we already branched the top level all their object link targets should exist. And so on to the third, fourth, etc., down through the hierarchy.
If the modules are all branched at once, BranchManager creates all the modules first , then links them, so their order doesn't matter.
With integration, there is not always a correct way. If you start at the top, you could attempt the merge of an object deletion, but maybe that object has an incoming link which
might prevent the deletion, and so you should integrate that source object first because the link is deleted during its merge. If you start at the bottom, you get the opposite
situation, you could attempt the merge of a link creation, but maybe the link's target has not been created yet, and so you should integrate the target object's creation first.
If you're looking for some general rules, here's what we suggest: Always work top-down. This always works for branching, and it works for integration EXCEPT for object deletions.
So while integrating a hierarchy of modules, for the first pass start at the top and work down but skip object deletions, and for each module do not abort or finalize,
press the continue later button. When you're done, do a second pass, start at the top, work down, integrate everything (should only be object deletions left), and for each module finalize.
Yes It will.
BM will merge new linksets, i.e. linksets created in the source of the changes being integrated. Of course,
there are conditions, but they are simple.
A new linkset will be merged if:
What that means is, if a new link module was created to store the linkset in the change source project, and thus does not have a parallel link module in the change target project, the linkset (and thus its links) will not be merged.
BranchManager will generate a temporary "Internal ID" if there is none or if it is wrong.
So there are no negative consequences, you can branch and integrate modules normally.
To display the triggers at module level:
Open the module,
Go to Tools -> Edit DXL,
Paste the code below and click on 'Run'
To check the triggers at project level, replace line 13 with the following and select the desired project in the left-pane:
for t in current Project do
To check the triggers at Database level, replace line 13 with the following:
for t in database do
Trigger t
bool flag = false
if(null current Module)
{
if (confirm "You don't have a module open.\nYou can only view details of triggers at Project/Database level if line 13 is modified as mentioned in TechNote")
{}
else
{
ack "You don't have a module open. Please open a module and run this script"
halt
}
}
for t in current Module do
{
string h=name (t )
string k=dxl (t )
print "----------------------------------\n"
print "Name of trigger: " h "\n"
print "DXL Code associated with trigger:\n" k "\n"
flag = true
}
if (!flag)
print "No triggers were found.\n"
print "----------------------------------\n"
Later version can read earlier version data. But earlier versions cannot read later versions