Team collaboration is the practice of working in a team instead of by one person. Team members can work individually on their own specific parts of a project and eventually combine works together to form a complete project. As a result of collaborations between members by employing the unique skills of each, works can be done more effectively and in higher quality.
Visual Paradigm‘s team collaboration support provides access to a central repository for managing, sharing and versioning projects. You can allow team members to get project from repository, start working on their own parts and allow them to commit (i.e. upload) their work to server as well as update others’ works. This chapter outlines some of the key concepts in team collaboration in Visual Paradigm.
Member and project management
Member and project management are processes of setting up members and projects and deciding the access rights of members against projects.
Checkout and open project
Checkout project is the process to get project from repository to start working with. Team members can login to the server, then checkout the project(s) to work with, provided that they have the permission to do so, as granted by administrator. After that, open to start working on it.
Commit
Commit is the process to upload changes done in working copy to server. As team members make changes in a project, they can share their works by committing those changes to the server. Visual Paradigm will try to merge changes from working copy to server copy. When merging, there may be conflict when any changes a team member made to cause an unresolvable contradiction with changes made by others. Team member is required to decide whether to keep his/her change (i.e. overwrite) or to take the co-worker’s change (i.e. revert). All conflicts must be resolved in order to proceed with committing.
Update
Update is the process of refreshing the working copy by merging changes that others had made and committed to server before. Similar to commit, update is a process of merging differences instead of overwriting. If your changes overlap the changes others had made, you will be asked to resolve conflict. All conflicts must be resolved in order to proceed with updating.
Conflict
Conflict is a situation that happens when committing or updating. It occurs during the merging between working and server copy of project, when a contradiction is detected between them. For example, a team member has renamed a shape from A to B and has committed the change. Then, another team member has renamed the same shape from A to C and attempt to commit. Due to difference in the name of shape, a conflict is occurred. Whenever a conflict occurres, you have to resolve it or else to abort before commit/update operation.
Branching
Branching is the process of creating a branch from trunk (i.e. main development flow), for isolating changes that are not supposed to be available on trunk, either at the moment or permanently. By working in a branch, team members can carry out half-broken or risky changes without worrying the risk of damaging the work in trunk. Once the works done in branch is examined and confirmed alright, team member can make changes available in trunk through merging. Merging can also be done from trunk to branch to ensure that the branch is always up-to-date.
Tagging
Tagging is the process of producing a snapshot (i.e. tag) of a project in time. People often create tags for archiving releases of works. Therefore, tags are often named as release-1.0 where 1.0 is the number of version. Since a tag is a snapshot, team members can never commit under a tag.
Revision history
Every time a team member performs a commit with success, a new revision is created as a snapshot of project. More and more revisions will be created through repeated committing. A list of revisions that shows the changes of project is called the revision history. In Visual Paradigm, you can review the works done in specific revision(s) by exporting them in project files. You can identify the differences between revisions by comparing them.
Revert changes
Revert is the process of undoing changes. In Visual Paradigm‘s team collaboration support, there are two kinds of revert actions that you can perform. The first one is to revert locally modified changes to make the working copy back to the original state. Another revert action is for undoing changes made in revisions. Team members can undo changes made in revisions by reverting them.