About version controlled objects
About objects controlled under the lock method
Version controlled objects, such as networks, can be created from scratch
or imported from another system. Each time you edit a version controlled
object or investigate some new scenario, a new version of the object is created
in the database. All previous versions of an object are available for inspection
at any time. To save space, only the differences between versions
are stored in the database.
It is essential that this collection of versions is carefully managed.
To help with this task, InfoWorks WS Pro contains a range of facilities for
maintaining the version controlled objects in a database.
InfoWorks WS Pro operates a rigid system of version control, which allows
changes that have been made to be tracked:
- To make changes to an existing version controlled object, it must be checked out to create
a new version.
- All previous versions
of an object are held within its model group
and can be viewed at any time.
- Although there may be one version controlled object
covering a complete model, variations of this can be created for
investigating potential changes in the model or for looking at smaller
parts of the model. These variations are called branches.
- A copy of a version controlled object can be made in a different location to the original object. These copies are called duplicates.
As a general rule, successive versions will show how the object has been
modified over time. A new version is created to add new objects
or change details of existing objects.
Branches are used for significant
variations or to investigate possible changes to the version controlled
object. A branch could be used to model a subset or a more detailed version
of a version controlled object, or to test the effects of a hypothetical
change to the object.
Duplicates are used to create a starting point for various analysis options. The duplicate retains a link to the object it was copied from in order to preserve version control.
Menu options allow new versions and branches to be created.
Before an existing version controlled object can be changed it must be checked out, either as a new version or as a branch.
When you have finished editing a version controlled object it should be checked in.
Version controlled objects can be inspected without creating a new version
or branch (although once a version
is checked in it cannot be edited).
More information about objects under the lock method
What is under version control under the lock method?
In InfoWorks WS Pro, the following objects are version controlled:
About checking out
There are two commands available for checking out a version controlled
object:
- Check out
- Check out and branch
You can think of the structure of network (or other version controlled
object) versions as similar to a real tree, with the original network (Main) being the trunk. When we first check out the Main network we begin to create
a branch.
You can use the command only on
the last object in a branch. Continuing the tree analogy, this object could
be described as the Leaf object. The effect of
checking out is to extend the branch, and the
newly checked out object becomes the Leaf at the
end of the branch.
If you want to test alternatives beginning at a point part-way along
an existing branch, then you must create a new branch from that point.
You do this using the
command.
You can now extend your new branch using or create more branches using .
It is perfectly valid to check out and branch
from the Leaf object of a branch. If you do this,
the effect is identical to using ,
but the icon used will be different, and your tree structure will be displayed
differently.
For this reason, it is sensible to develop a policy about when you use
or . We would recommend that you use for on-going development and changes to your core model. is used when looking at alternative
proposals and doing the What If type of analysis.
Of course, this doesn't prevent one of your branches becoming the basis
for a new core model if a particular proposal is implemented.
About duplicating
The command is used to create a copy of a version controlled object in a different location in the tree to the original object. This may be done to create a new starting point for various analysis options.
Duplicating an object in effect carries out a check out and branch of the original object. However, the duplicate is created in a user specified model group and is checked in at the end of the branching process.
About validating
The only version controlled object in InfoWorks WS Pro that needs to be validated
is the network.
Networks need to be validated before they
can be used as part of a simulation. Networks can
be validated at any time, whether or not they are checked out. If you
attempt to check in an object that requires validation, but that has not
been validated, you will be prompted to validate before check in.
Important: You
can ignore the prompt and check in anyway, but, once an invalid object has been checked in it cannot be
edited. The object cannot be used in simulations because it contains errors.
You will have to check the object out again (make a new version) to repair
errors before it can be validated. For this reason, you should always
make sure objects are validated and without errors before checking in.
Validation errors are displayed on the Output
window and you can jump to the relevant error from this window.
About comparing version controlled objects
About comparing based on Asset ID
Networks can be compared by comparing objects, or sets of objects with
the same Asset ID instead of using the Object ID. This functionality is
particularly useful in cases where an asset is represented by more than
one network object.
Example
|
|
A pipe is represented by two network model conduits. Both pipes have
the same Asset ID value.
|
When comparing networks based on Asset ID:
- For each Asset ID found in Network 1 (network
to be compared), a check is carried out that the same network objects
make up the asset in Network 2 (network to be compared with):
- If the Object IDs are the same, a field by
field comparison of the objects making up the asset is carried out. Corresponding
objects from each network are compared. If any of the objects making up
the asset have differing field values, the before and after field values
for all of the objects making up the asset will be reported.
- If the Object IDs are not the same, for example
if a Node ID has been changed, the asset will be reported as being modified.
- Any Asset IDs found in Network 2 that are not
in Network 1 are reported as additions.
- Any Asset IDs found in Network 1 that are not
in Network 2 are reported as deletions.
Object IDs of all objects making up a reported asset are included in
brackets after the Asset ID in the report.
The following rules also apply when comparing by Asset ID:
- Comparison of network objects is carried out separately
for each network type. Therefore, a change to a node asset will not be
reported as a modification of a pipe asset with the same Asset ID.
- Network comparison results cannot be output to a
CSV file when comparing based on Asset ID.
- Network objects that do not have an Asset ID field,
e.g. polygons, will not be compared or reported.
- Network objects with an empty Asset ID field will
not be compared. The number of objects without an Asset ID will be reported.
- If comparing a selection, modifications may be
reported if not all of the objects making up an asset are included in
the selection.
About outputting to screen or a text file
InfoWorks WS Pro compares the first object selected (in the Compare
this box) with the object or objects in the With
box. Therefore, this functionality will most likely be used with the more
recent object in the Compare this box.
Differences between the two version controlled objects are listed in the
General Text File view
or to a file depending on the output option selected. For each table in
the version controlled object, the report lists:
- all network objects that have a field or fields
that have changed (details are given of every difference)
- all network objects that exist in one version
but not in both
About outputting to a CSV file
In CSV mode, a CSV file is created containing all the data from the
first object that is different from that in the second object.
(Note that output to CSV file cannot
be used when comparing based on Asset ID.)
To export the changes that have occurred to a network, the object in the
Compare this box should be the more recent object.
The older object should be in the With box.
InfoWorks WS Pro creates a CSV file containing all the data from the first
object that is different from that in the second object. The CSV file contains
an additional Action column which is used
to denote network objects that have been deleted between versions.
The format of the CSV file is identical to that created when exporting
a version controlled object to a single CSV file, with the additional Action column. The Action
column allows additional options when reimporting CSV data, and provides
additional information when viewing the comparison results outside InfoWorks WS Pro.
Two characters may be added to the Action
column during comparison:
- The - (minus) character is added for network objects
that have been deleted between versions. This character is used when updating a network in Mixed
mode to delete the appropriate network object.
- The + (plus) character is used to denote network
objects that have been added between versions. This character is ignored
when updating. The standard update method will cope with adding network
objects.
About objects controlled under the merge method
The merge method available in InfoWorks WS Pro is a multi-user version control system that allows
concurrent editing of certain network objects.
The merge method allows teams of people to work seamlessly on the same network and then merge their changes together.
This version control system is also very efficient for single users, allowing
small changes to be made to networks quickly and easily.
There will inevitably be several versions of an object controlled under the merge method. When you first use such an object (for example, a network in a run simulation), the latest version will be used by default, although you will be able to specify that another version is used instead. When reusing a version controlled object, the version that was last specified will be reused, unless you use the update feature to specify that the latest version should be used. This is described in the help for the Schedule Hydraulic Run view.
