With the Team Development feature in TimeXtender, it is possible for multiple users to work together on the same project. By utilizing and respecting the work items you can ensure that only one person is changing a single object at a time and you can avoid corrupting the project.
Follow the rules below to ensure that the project stays consistent:
1) Never work on the same object as anyone else. An object is defined as Table, Dimension, Cube
- To avoid this, ALWAYS create work items before making any changes to an object. (Right-click the object, create work item)
- Create work items on associated objects that may be impacted by your changes. This should be any other object(s) that will be marked "dirty" (turn red) when your change is made.
- Example: When creating a conditional lookup. This updates the indexes on the source table and it will be marked as dirty. So both the source & target tables should be marked as work items.
- Example: Deleting a field that is mapped to a Data Warehouse will cause the data warehouse table to be marked as dirty. Create work items on both the source & target tables.
- Example: Updating a project variable will mark all objects where the variable is used as dirty. Create work items on all objects where the variable is used.
- Example: Modifying a script action and updating items where the script action is used. All objects that are updated should be marked as work items.
- If anyone else has the item marked for their use, wait for them to release the work item.
- Once you are done working on an object, Run a Save and Reload and release the work item.
- Keep the work items window open when working and be aware of other users work items.
2) Do not rename tables, cubes, dimensions.
- The only exception is if you just created the table and have not saved yet or if nobody else has the project open. (you can see who has an open project in the work items dialog)
3) Always Save and Reload (CTRL + F5) before you start a new development task. This makes sure that you get the latest version of all objects before you start taking over somebody else’s work.
4) Configure a daily (or more frequent) backup of the project repository. This can be used in the event a conflict and subsequent corruption occurs.