Recommendations on Working with Project Version Control

Be collaborative

• Multiple users that work collaboratively on the same project should agree on their responsibility for certain parts of the project where they do changes to avoid conflicts and tree conflicts.
• Agree on locking strategy used by all users working on the same project.
• Distribute the work between multiple users meaningful.
  • It is suggested to setup the hardware structure at first before other users checkout a project to work on it and limit structure changes in the hardware tree to the minimum.
  • Before adding objects, especially top level objects, users should agree that only one user adds objects at top level or below the same parent, or agree on unique names for the objects to add. The default naming scheme for new objects bears the risk of name conflicts. These conflicts could be resolved only by reverting the changes of the user who later tried to commit the changes.

Be careful

• The SVN integration (and also project compare) gives lot of power to the user, users should be sure to do only things they fully understand. Especially by merging changes incomplete it is possible to create inconsistent data.
• Adding devices, removing devices or even changing parameters can have side effects to other devices, do not change objects/parameters to their original state by merging that were not done explicitly.
• Commit changes frequently to SVN.
  • Torelease locks that you don’t longer need.
  • Toreduce the risk of conflict with co-workers.
  • To keep the sets of changes to commit small.
• Do frequent updates when collaborating in a team.
  • To be up-to date.
  • To keep the sets of changes to get from SVN small.
  • To reduce the risk of losing work results in case of conflicts.
• To avoid conflicts, it is suggested to stay with the default setting to automatically lock objects before doing changes. Consider explicit recursive locks of sub-trees where you plan bigger changes.
• Prefer a clean checkout over using the switch command to change between different branches.
• Do not use the switch command to change between unrelated projects, this could corrupt the Automation_Builder project (local copy, not in SVN) easily.
• Commit local changes to the SVN repository before creating a branch.

Be effective

• Give objects good/correct names after adding them and use renaming of objects already committed to SVN sparely to maintain a continuous history in the SVN repository.
• The goal to revert only single changes of all changes done that must be committed/reverted together, could be achieved by using project compare or the object compare dialog.
• If changes can’t be committed to the SVN repository because of locks hold by other users, it is possible to create a branch, use the switch command to change to this branch and commit the changes there. The branch and base line could be merged together later.