This document is a reference guide for the BdbIntervalUtil. The utility provides a broad spectrum of browsing and management commands related to the contents of Conditions database.

Due to "referential" nature of this document its scope is only limited to a short description of each command without going deep into details. This will be covered by another document.

Each command is documented with:

A short description of its functionality and side effects;
A definition of the syntax;
A list of parameters;
Authorization requirements;
A sample output of the command in case of errors.

The commands are grouped into groups according to their functionality.

1.1 General notes on the syntax

The Utility is able to execute just one command at a time. It's not possible to read commands from a file.

The general syntax recognized by the utility is:

BdbIntervalUtil <command> [<parameters>]

The command is an atomic action to be executed by the utility. Each command has a list of parameters specific to this command.

1.2 Transaction management

The transaction management policy for those commands meant to modify the contents of the Conditions/DB is as follows:

An update-mode transaction is unconditionally aborted if any kind of problems is encountered during the command's execution or even at the preparation stage (like command parsing stage).
For the composite commands (the ones involving starts or commits of multiple transactions to complete specified mission) the previously stated rule (1) applies only to a transaction where a problem occurs. Should this occur the command's execution is immediately aborted as well. This actually means that the composite commands may be "semi-completed".

By default (unless it's stated explicitly) commands are executed within a single transaction. Multiple transaction mode is typically used when multiple interval containers are involved into an operation, or if this is required by the performance consideration.

See the description of each command for an indication if this command is the composite one.

1.3 Authorization

The current authorization policy for the Conditions/DB requires that each detector of the Conditions/DB be mapped onto a separate authorization group. Therefore only members of a group as well as all so called "System Managers" of the Conditions domain are allowed to modify conditions of the corresponding detector.

A practical consequence of the mentioned above rule is that a user must be registered as a member of the group in order to modify the conditions of the detector/group.

In addition, some of the operations involving conditions from multiple detectors require a user to be either a System Manager of the Conditions domain or be a member of every single group affected by the operation.

The list of all registered users in the Conditions domain of a federation can be obtained with the following command:

BdbAuthCmd lsusers Conditions

A list of known authorization groups (for the Conditions domain) can be obtained with:

BdbAuthCmd lsgroups Conditions

Here is how to get a list of members of a particular group (emc in this example):

BdbAuthCmd lsmembers Conditions emc

See "BaBar Database Authorization API and Authorization Management Utility" for other details, especially on how to create new groups and register new group members.

1.4 Completion of the commands

Upon a command completion the following values are returned to a shell:

0 - success

1 - error

The detailed information about the error is printed onto a standard output stream. The meaning of the error status for the complex commands (the ones whose execution involves multiple transactions) depends on a command. In some cases the command's execution may be considered as semi-successful.

1.5 The version of this document

The description of the utility and other related software components presented in this document are valid for the following ranges of BABAR software releases:

· From release 9.6.0

· Up to (including) 9.9.2

The partial compatibility with previous and past releases is also available. See the self-descriptive help command of this utility for a list of commands supported in a specific version.

This document will be updated as new releases are issued.

2. The commands description

2.1 General information

2.1.1 help

DESCRIPTION:

This command will print onto the standard output stream the information on this utility in a form of a simple list of lines. The content of the output is a non-structural subset of information presented in the current document.

SYNTAX:

BdbIntervalUtil help

PARAMETERS:

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil help

DESCRIPTION:

  This Utility provides a broad spectrum of various browsing

  and management commands which relate to the contents of Conditions database.

  IMPORTANT: The transaction management policy for those commands which are

             meant to modify the contents of the Conditions/DB is as follows:

             1. An update-mode transaction is unconditionally aborted if any kind of

                problems is encountered during the command's execution or even at

                the preparation stage (like command parsing stage).

...

2.1.2 detectors

DESCRIPTION:

Print names of sub-detectors groups in the Conditions database. This command (in its current implementation) will make and parse a dump of the existing con_xxx_Link databases using the oodumpcatalog utility.

Make sure that the mentioned above utility is in your current path. Note also, that for some federations with many databases this may take a while. Just be patient.

SYNTAX:

BdbIntervalUtil detectors

PARAMETERS:

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil detectors

emc

dch

ifr

...

2.1.3 containers

DESCRIPTION:

Print names of conditions for specified detector group. Additional options are controlling how much information to show about found containers. It's also possible to specify exactly where the conditions have to be searched.

SYNTAX:

BdbIntervalUtil containers <detector>

                [-all] [-long]

                [ { ALL | NEWLINK | NEWINDEX [<origin>] | OLDINDEX } ]

PARAMETERS:

Mandatory	<detector>		This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
Optional	-all		This optional parameter forces the command to include conditions with special names starting with underscore symbol '_'. These names are reserved for the internal use by the Conditions/DB implementation. They are not normally shown if this optional parameter is not explicitly specified.
	-long		This optional parameter forces the command to print basic characteristics of each of the found condition. This includes the following: If the persistent bookkeeping is on for this condition then [HISTORY] will appear in the output. This keyword will never seen for the old style databases. The so called origin of a condition is shown with [ORIGIN:xxxx] where xxxx is the origin name. This keyword will never seen for the old style databases. Some conditions can be declared as read-only at a given federation. If this is a case then [READONLY] will appear for this conditions. This kind of protection can be set by a special command of BdbIntervalUtil. See commands locklink and unlocklink for details. See examples below.
	Mutually exclusive	ALL	To find and print both old containers in old interval database (OLDINDEX) and new container links in link database (NEWLINK).
		NEWLINK	To find and print containers found in con_<detector>_Link link database.
		NEWINDEX [<origin>]	To find and print containers found in an index interval database con_<detector>_Index_<origin> for specified origin. If no origin is specified then the local one is used.
		OLDINDEX	To find and print only those containers found in the legacy con_<detector>_Index interval database.

AUTHORIZATION:

EXAMPLES:

% BdbIntervalUtil containers emc

AAA

EmcFooClassP

BBB

% BdbIntervalUtil containers emc -all -long

[HISTORY][ORIGIN:default]  AAA

[HISTORY][ORIGIN:default]  EmcFooClassP

[HISTORY][ORIGIN:default]  _CHECKPOINT_3151268353_EmcFooClassP

...

2.2 Genealogy browsing

2.2.1 genealogy

DESCRIPTION:

Print the information about persistent intervals for specified condition. The output is available in various formats. The validity range can also be optionally narrowed from either or both sides of the validity timeline.

SYNTAX:

BdbIntervalUtil genealogy <detector> <container>

                [-format <number>]

                [-begin_validity <time> [-begin_validity_tzone <zone>]]

                [-end_validity   <time> [-end_validity_tzone   <zone>]]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
	<container>	The condition name.
Optional	-format <number>	This parameter controls the output format of the dump. More information on the known format numbers and how they would affect the output of the dump is available at: “The formats of genealogy dumps”.
	-begin_validity <time>	This parameter is meant to specify the left limit for the genealogy dump in the validity time. By default the dump begins from the logical minus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the left validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.
	-end_validity <time>	This parameter is meant to specify the right limit for the genealogy dump in the validity time. By default the dump ends at the logical plus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the right validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil genealogy emc EmcFooClassP

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

1  2997907200:2997907210  V0  [9219-6-3-18] -> [9217-3-1-25]  Rev.0

1.0  2997907200:2997907210  V1  [9219-6-3-55] -> [9217-3-1-28]  Rev.*

2  2997907210:2997907220  V0  [9219-6-3-41] -> [9217-3-1-26]  Rev.0

2.0  2997907210:2997907220  V1  [9219-6-3-60] -> [9217-3-1-28]  Rev.*

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-28]  Rev.0

...

2.2.2 toplist

DESCRIPTION:

This command prints a subset of the genealogy information corresponding to the TOPMOST layer of intervals only. The red intervals on a picture below are those ones printed by the command:

SYNTAX:

BdbIntervalUtil toplist <detector> <container>

                [-format <number>]

                [-begin_validity <time> [-begin_validity_tzone <zone>]]

                [-end_validity   <time> [-end_validity_tzone   <zone>]]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
	<container>	The condition name.
Optional	-format <number>	This parameter controls the output format of the dump. More information on the known format numbers and how they would affect the output of the dump is available at: “The formats of genealogy dumps”.
	-begin_validity <time>	This parameter is meant to specify the left limit for the genealogy dump in the validity time. By default the dump begins from the logical minus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the left validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.
	-end_validity <time>	This parameter is meant to specify the right limit for the genealogy dump in the validity time. By default the dump ends at the logical plus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the right validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil toplist emc EmcFooClassP

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

*  2997907200:2997907210  V1  [9219-6-3-55] -> [9217-3-1-28]  Rev.*

*  2997907210:2997907220  V1  [9219-6-3-60] -> [9217-3-1-28]  Rev.*

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-28]  Rev.0

...

2.2.3 baselinelist

DESCRIPTION:

This command prints a subset of the genealogy information corresponding to the BASELINE layer of intervals only. The red intervals on a picture below are those ones printed by the command:

SYNTAX:

BdbIntervalUtil baselinelist <detector> <container>

                [-format <number>]

                [-begin_validity <time> [-begin_validity_tzone <zone>]]

                [-end_validity   <time> [-end_validity_tzone   <zone>]]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
	<container>	The condition name.
Optional	-format <number>	This parameter controls the output format of the dump. More information on the known format numbers and how they would affect the output of the dump is available at: “The formats of genealogy dumps”.
	-begin_validity <time>	This parameter is meant to specify the left limit for the genealogy dump in the validity time. By default the dump begins from the logical minus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the left validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.
	-end_validity <time>	This parameter is meant to specify the right limit for the genealogy dump in the validity time. By default the dump ends at the logical plus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the right validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil baselinelist emc EmcFooClassP

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

*  2997907200:2997907210  V0  [9219-6-3-18] -> [9217-3-1-25]  Rev.0

*  2997907210:2997907220  V0  [9219-6-3-41] -> [9217-3-1-26]  Rev.0

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-28]  Rev.0

...

2.2.4 revisionlist

DESCRIPTION:

This command prints a subset of the genealogy information for intervals belonging to the specified revision either directly or indirectly. The red intervals on a picture below are those ones printed by the command:

SYNTAX:

BdbIntervalUtil revisionlist <detector> <container> <revision_id>

                [-format <number>]

                [-begin_validity <time> [-begin_validity_tzone <zone>]]

                [-end_validity   <time> [-end_validity_tzone   <zone>]]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
	<container>	The condition name.
	<revision_id>	The revision number of intervals to be displayed. This is a 32-bit unsigned integer number. Decimal format is expected.
Optional	-format <number>	This parameter controls the output format of the dump. More information on the known format numbers and how they would affect the output of the dump is available at: “The formats of genealogy dumps”.
	-begin_validity <time>	This parameter is meant to specify the left limit for the genealogy dump in the validity time. By default the dump begins from the logical minus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the left validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.
	-end_validity <time>	This parameter is meant to specify the right limit for the genealogy dump in the validity time. By default the dump ends at the logical plus infinity. See more information on how to specify the time at: “How to specify day and time”.
		Optional	This optional parameter is bound to the right validity time limit. It’s meant to override the default time zone for the validity time, which is “local” in the current implementation of the utility. See format of this parameter at: ”How to specify the time zone”.

AUTHORIZATION:

EXAMPLE:

% BdbIntervalUtil genealogy emc EmcFooClassP

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

1  2997907200:2997907210  V0  [9219-6-3-18] -> [9217-3-1-25]  Rev.0

1.0  2997907200:2997907210  V1  [9219-6-3-55] -> [9217-3-1-28]  Rev.1

1.0.0  2997907200:2997907210  V2  [9219-6-3-83] -> [9217-3-1-29]  Rev.*

2  2997907210:2997907220  V0  [9219-6-3-41] -> [9217-3-1-26]  Rev.0

2.0  2997907210:2997907220  V1  [9219-6-3-60] -> [9217-3-1-28]  Rev.1

2.0.0  2997907210:2997907220  V2  [9219-6-3-85] -> [9217-3-1-29]  Rev.*

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-29]  Rev.0

...

% BdbIntervalUtil revisionlist emc EmcFooClassP 0

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

*  2997907200:2997907210  V0  [9219-6-3-18] -> [9217-3-1-25]  Rev.0

*  2997907210:2997907220  V0  [9219-6-3-41] -> [9217-3-1-26]  Rev.0

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-29]  Rev.0

...

% BdbIntervalUtil revisionlist emc EmcFooClassP 1

*  -Infinity-:2997907200  FirstInterval  [9219-6-3-17] -> [0-0-0-0]  Rev.0

*  2997907200:2997907210  V1  [9219-6-3-55] -> [9217-3-1-28]  Rev.1

*  2997907210:2997907220  V1  [9219-6-3-60] -> [9217-3-1-28]  Rev.1

*  2997907220:+Infinity+  LastInterval  [9219-6-3-48] -> [9217-3-1-29]  Rev.0

...

2.3 Managing containers

2.3.1 delete

DESCRIPTION:

Delete specified interval container and all the objects pointed through intervals of the container if required by optional argument.

By default this operation will delete both the container link from con_xxx_Link databases and the interval container from con_xxx_Index_<origin> database. This kind of behavior can be changed by setting an optional parameter to avoid deleting the symbolic link.

Note that containers which are declared as read-only (see containers command) can not be deleted in this way. This has to be fixed by the unlocklink command before doing this operation.

SYNTAX:

BdbIntervalUtil delete <detector> <container> [-objects] [-nolink]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
Mandatory	<container>	This is the condition name to be affected by the operation.
Optional	-objects	If this optional parameter is specified then all the condition objects following from persistent intervals will be deleted as well.
Optional	-nolink	If this optional parameter is set then the symbolic link container will not be deleted. One important consequence of this is that when the operation is finished the link will point to non-existing interval container.

AUTHORIZATION:

A user must be a member of a detector group where the deleted container is located.

EXAMPLE:

% BdbIntervalUtil containers emc -all -long

[HISTORY][ORIGIN:default]  AAA

[HISTORY][ORIGIN:default]  EmcFooClassP

[HISTORY][ORIGIN:default]  _CHECKPOINT_3151268353_EmcFooClassP

...

% BdbIntervalUtil deletemany emc AAA

...

2.3.2 deletemany

DESCRIPTION:

Delete many interval containers at a detector whose names match a simple regular expression. For each eligible container the command behaves exactly as a single container deletion command.

Names of deleted containers can optionally be reported to the Standard output stream if the verbose mode is chosen.

If at least one read-only container is met in the list of the eligible one then all the operation fails. See more details on that subject from the single container deletion command's description.

The special containers (starting with underscore prefix) will also be deleted if they match the specified regular expression.

SYNTAX:

BdbIntervalUtil deletemany <detector> <regexpr> [-objects] [-nolink] [-verbose]

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
Mandatory	<regexpr>	A simple expression for the container names to be selected for the deletion. See the description of RWCRegexp class, which is used in the current implementation of the command, for the complete description and limitation of the syntax. Here are simple expressions: "", "Class", "My*Class".
Optional	-objects	If this optional parameter is specified then all the condition objects following from persistent intervals will be deleted as well.
	-nolink	If this optional parameter is set then the symbolic link container will not be deleted. One important consequence of this is that when the operation is finished the link will point to non-existing interval container.
	-verbose	Forces the command to print the names of deleted containers.

AUTHORIZATION:

A user must be a member of a detector group where the deleted containers are located.

EXAMPLE:

% BdbIntervalUtil containers emc -all -long

[HISTORY][ORIGIN:default]  AAA

[HISTORY][ORIGIN:default]  EmcFooClassP

[HISTORY][ORIGIN:default]  _CHECKPOINT_3151268353_EmcFooClassP

...

% BdbIntervalUtil deletemany emc "*" -verbose

DELETE: emc AAA

DELETE: emc EmcFooClassP

DELETE: emc _CHECKPOINT_3151268353_EmcFooClassP

...

% BdbIntervalUtil containers emc -all -long

...

2.3.3 copy

DESCRIPTION:

Make a copy of an interval container and optionally all the condition objects being registered through the original container. The output interval container may be located either in the same detector or in the other one. The new container is always created in an interval database corresponding to the local origin of a federation where this operation is being performed.

As an option, only a part of the whole genealogy from the input container can be copied into the output one. Possible options include: copy baseline intervals only, copy topmost intervals only and copy a specific revision slice only. By default all the intervals information is copied.

IMPORTANT: The history records are not copied during this operation. A special record is placed into the history of the output container to indicate that this container is created as a copy of the other one.

The condition objects are copied only if required by the corresponding switch. If this is the case then by default the output condition objects are created in object databases of the output detector as it’s suggested by the regular clustering hint. As an option these objects can also be created in a separate container (whose name must be explicitly specified by a user) located in the same interval database where the copy of an interval container is placed. In this case a user should follow some naming convention for these (data) containers, for example by using the following prefix in front of these names "_DATA_<time>_" followed by the interval container name. See examples below.

IMPORTANT: In the current implementation of the code so called composite objects are copied just partially.

SYNTAX:

BdbIntervalUtil copy <from_detector> <from_container>

                     <to_detector>   <to_container>

                     [-l<level> [<revision_id>]]

                     [-objects  [-local <container>] [-warnings]]

PARAMETERS:

mandatory	<from_detector>	The detector name where the input condition is located.
	<from_container>	The input condition name.
	<to_detector>	The output detector where a copy of the input container will be placed. This can be the same detector as the input one.
	<to_container>	The output condition/container name. If the output detector is the same as the input one then this name must be
optional	-l<level>	This parameter specifies the genealogy copy level. It allows to force the command to copy a subset of intervals into the output container. The following values for his parameter are allowed: -ld all the genealogy information is copied. This is the default behavior of the command. -lb baseline intervals are copied only. -lt topmost intervals are copied only. -lr intervals that belong (either directly or indirectly) to the specified (through the next parameter) revision are copied only.
		optional		<revision_id>	This normally optional parameter is required if the previous parameter requires that a revised slice of intervals has to be copied.
	-objects	This parameter forces the command to make a deep copy of the persistent condition objects registered via the intervals. By default the new objects are placed into object databases of the output detector as it’s defined by the clustering policy of the Conditions/DB.
		optional	-local <container>			This parameter allows to override the default clustering policy and to store the output objects into a separate container in the output interval database alongside with the newly created copy of interval container. It’s advised to follow some policy when copying condition objects using this combination of parameters. So for example the container name for this (data) container should start from the underscore (‘_’) to indicate that this is going to be a special container.
			-warning			This tells the command to issue a warning every time the virtual table for the copied persistent condition object is not loaded.

AUTHORIZATION:

A user must be a member of a to_detector group where the output containers are placed.

EXAMPLE:

% BdbIntervalUtil containers emc -long

[HISTORY][ORIGIN:default]  EmcFooClassP

...

% BdbIntervalUtil copy emc EmcFooClassP emc AAA

...

% BdbIntervalUtil containers emc -long

[HISTORY][ORIGIN:default]  EmcFooClassP

[HISTORY][ORIGIN:default]  AAA

...

% BdbIntervalUtil containers tmp –long

...

% BdbIntervalUtil copy emc EmcFooClassP tmp EmcFooClassP –objects –local _DATA_EmcFooClassP

...

% BdbIntervalUtil containers tmp –all

EmcFooClassP

_DATA_EmcFooClassP

...

2.3.4 checkpoint

DESCRIPTION:

Create a checkpoint of an interval container. The checkpoint is a copy of specified interval container into another one having a special normally invisible name. The basic idea of this operation is to take a snapshot of the genealogy information for a specified condition at a given time. Since the snapshots have unique names (bound to a time when this operation is performed) then there may be as many snapshots of a particular condition as it's required.

This operation does not involve the condition objects themselves, but it does create a new name in the link database for a new condition. This name is build from the original condition name preceded by a prefix "_CHECKPOINT_<time>_". The <time> in this prefix is represented as the number of seconds since January 1, 1901.

No matter what's the origin of an original condition the new interval container is created in an interval database corresponding to the local origin of a federation where this command is being executed.

The checkpoints can be seen when running the containers command with on optional switch -all.

Since checkpoints are much like the regular containers then they can be deleted in the same way as the regular ones using delete or deletemany commands. It's very important however to remember that all intervals at a checkpoint have references to the same condition objects as the intervals from the original container do. So avoid deleting the checkpoints using -objects switch of the deletion commands. Otherwise the original interval container (as well as any other remaining checkpoints of this condition) will have so called dangling references to non-existing condition objects. The same rule should be followed when deleting the original condition with -objects switch. In that case all checkpoints must be deleted as well.

SYNTAX:

BdbIntervalUtil checkpoint <detector> <container>

PARAMETERS:

Mandatory	<detector>	This mandatory parameter narrows search to a specific detector group. Make sure that specified detector exists.
Mandatory	<container>	This is the condition name to be affected by the operation.

AUTHORIZATION:

A user must be a member of a detector group where the deleted containers are located.

EXAMPLE:

% BdbIntervalUtil containers emc -all -long

[HISTORY][ORIGIN:default]  EmcFooClassP

...

% BdbIntervalUtil checkpoint emc EmcFooClassP

...

% BdbIntervalUtil containers emc -all -long

[HISTORY][ORIGIN:default]  EmcFooClassP

[HISTORY][ORIGIN:default]  _CHECKPOINT_3151268353_EmcFooClassP

...

% BdbIntervalUtil delete emc _CHECKPOINT_3151268353_EmcFooClassP

...

2.3.5 merge

2.3.6 verifymerge

2.3.7 merge2

2.3.8 verifymerge2

2.3.9 split

DESCRIPTION:

Split a timeline of a condition at a given point of validity time. This operation will make a vertical genealogy “cut” at this point. The condition objects themselves are not affected by this operation. The output of the “fetch” operations will also be the same as before. The only purpose of this operation is to change the internal structure of intervals.

Here is an example of what is happening to the genealogy

Table of contents

1. Introduction

1.1 General notes on the syntax

1.2 Transaction management

1.3 Authorization

1.4 Completion of the commands

1.5 The version of this document

2. The commands description

2.1 General information

2.1.1 help

2.1.2 detectors

2.1.3 containers

2.2 Genealogy browsing

2.2.1 genealogy

2.2.2 toplist

2.2.3 baselinelist

2.2.4 revisionlist

2.3 Managing containers

2.3.1 delete

2.3.2 deletemany

2.3.3 copy

2.3.4 checkpoint

2.3.5 merge

2.3.6 verifymerge

2.3.7 merge2

2.3.8 verifymerge2

2.3.9 split