All users make changes to their individual working copies as usual in Control FPWIN Pro7. Users compile, download, and test as needed or appropriate.
Some additional manual work on the working copy is necessary in case users add, delete or rename an object with Control FPWIN Pro7.
Operating directly on the folders and files of the working copy (e.g. edit, delete, create, paste, rename) may destroy the working copy and the project or the user library!
In the working copy, make sure to use only the commands of the external version-control system that manages the data exchange between the working copy and the corresponding repository when you open a context menu!
Every user can see overlay icons of the folders and files in the file explorer telling them about the change state of the local object/file/folder compared to the original revision they received from or committed to the project or user library repository.
At any time, users can inspect the local changes they applied to their working copy (object-wise or file-wise) since the moment when they received it from the project or library repository (without merging their own changes) or when they committed their changes. They can also compare the current state of their working copy to any revision of the project or library in the corresponding repository (users can also compare any two revisions in the project or library repository).
Users inspect and double-check their changes before committing them to the corresponding repository.
Users can undo the local changes in their working copy by reverting it object-wise or file-wise (the file is the smallest unit which can be reverted), partially (on subfolder level) or completely (the whole working copy folder). The reversion will automatically also be done in the open project or user library.
Users commit their changes on their individual working copies to the corresponding repositories, e.g. if or when one or more other users need objects that are new or have been changed elsewhere.
The first user to commit changes can do so without any queries from the system.
The second and all subsequent users to commit their changes may be required to update their working copy before being able to commit their changes so that changes which have been made by other users to the same object(s) can be merged into their (changed) objects first.
The merge process only takes place when the working copy is updated from the corresponding repository. A successful merge always completely replaces the appropriate object in the project file. If the merge is not successful, it may be due to conflicting changes to the same object, for example two users used two different initial values for the same variable. In this case, all users keep their own version until the conflict is resolved. Objects and files with unsolved conflicts remain in the working copy folder until these conflicts are resolved.
If the merge cannot be done automatically, the resulting merge conflict has to be resolved manually with the help of the used version-control system's tools and menus.
With each commit into a project or library repository, a comment text should be added that helps other users to understand the committed changes (what is changed and why, maybe an error or work package number). Revision number, author, and date and time are automatically added and can be inspected at any time with the objects’ log data (history).
At any time, users can inspect the change history of the objects/files in the project or library repository from their working copy and see who changed what, when and why (the why depends on whether the previous commits have been done with comments).
All users can update their working copy from the corresponding repository, e.g. if they need or want to integrate the objects or changes from the other users. Any merge conflicts during this update have to be resolved manually with the help of the used version-control system's tools and menus. After successful update or resolving of any merge conflicts, the changes are automatically incorporated and merged into the users' working copy as follows:
When the project is closed, the nested working copy is updated, and the project and the user libraries are updated from the nested working copy the next time the user opens the project. The (nested) working copy is the (local) master over the project file with its version-controlled user libraries!
When the project is open, all changed objects are updated automatically unless they are currently open in an editor.
Objects that are currently open in an editor will be updated depending on their change status:
Unchanged objects: The merge process closes the editor window and updates the object. When the user re-opens the object, it will be in the updated state.
Changed objects: A message appears and asks the user to decide whether the current changes in the editor should be discarded or saved. When the current changes are discarded, the editor is closed and the object is updated. If the current changes are saved, the object will not be updated.
All users can go back to an earlier revision in the project or library repository by updating or reverting their working copy to that revision. This will automatically be reflected in their project or library, too. However, any changes made to the reverted working copy cannot be committed to the repository since they are based upon an obsolete revision.