Previous: Working with branch per task
First you create your new work branch, now you can’t keep modifying the master task branch anymore because a second developer is in and you wan’t have conflicts with both modifications. You must think on a branch as a personal directory that one and only one developer can modify directly. Always that 2 or more developers need to modify one branch, they do that using sub-branches of the task, and updating the main task only with merges, never directly.
So let’s create your dev-1 work branch, modify form1 and add 2 new controls (lblLastName and txtLastName) , save the form, generate the text files for pending changes and checkin the 3 files combo (scx/sct/sc2):
![plasticscm_en_work_24_New_dev-1_branch_and_form1_modification.png]( "plasticscm_en_work_24_New_dev-1_branch_and_form1_modification.png")
While your where doing this, dev-2 came in, created his dev-2 work branch, modified form1 and added 2 new controls (lblSex and txtSex):
![plasticscm_en_work_25_New_dev-2_branch_and_form1_modification.png]( "plasticscm_en_work_25_New_dev-2_branch_and_form1_modification.png")
So the Branch Explorer show this with both modifications, each one on a different sub-branch:
![plasticscm_en_work_26_form1_both_modifications.png]( "plasticscm_en_work_26_form1_both_modifications.png")
Now we need to merge both changes, and this is the best part: The first developer that merges their changes, get an automatic merge, and second developer that merge, almost surely must resolve the conflicts, so you commit first :-)
Switch to task_001 so the home icon shows there:
![plasticscm_en_work_27_form1_dev-1_change_to_main_task.png]( "plasticscm_en_work_27_form1_dev-1_change_to_main_task.png")
And now you can merge, process all merges (automatic) and commit:
![plasticscm_en_work_28_form1_dev-1_commit_first.png]( "plasticscm_en_work_28_form1_dev-1_commit_first.png")
And now dev-2 does the same, and process the merges, but he must resolve 3 conflicts in this case (look at the “Non automatic. User intervention needed” message on the upper-left and the “Pending non-automatic: 3/3” counter on the upper-middle). As you can see, both changes must be implemented:
![plasticscm_en_work_29_form1_dev-2_commit_second_non_automatic.png]( "plasticscm_en_work_29_form1_dev-2_commit_second_non_automatic.png")
So dev-2 click on top button “Mark as resolved” and find the second conflict, on which both controls code is shown. As earlier, we use the same solution and “Mark as resolved” because we need both codes:
![plasticscm_en_work_30_form1_dev-2_commit_second_non_automatic_conflict_2.png]( "plasticscm_en_work_30_form1_dev-2_commit_second_non_automatic_conflict_2.png")
The last conflict, in this case, is an easy one to resolve, like earlier, so same resolution:
![plasticscm_en_work_31_form1_dev-2_commit_second_non_automatic_conflict_3.png]( "plasticscm_en_work_31_form1_dev-2_commit_second_non_automatic_conflict_3.png")
As you can see, the counter shows 0 conflicts now, so we can click “Save & Exit”, and this finishes the text merge, but we have left the binaries. What we do with them?
![plasticscm_en_work_32_form1_dev-2_commit_second_pending_merge_binaries.png]( "plasticscm_en_work_32_form1_dev-2_commit_second_pending_merge_binaries.png")
That’s the easy part: we have merged the only files that can be merged, the text files that represent those binaries, so in this case the binaries must have left untouched because we are going to regenerate them in the Pending Changes view!
Now let’s bypass those binaries:
![plasticscm_en_work_33_form1_dev-2_commit_second_preserve_workspace_changes.png]( "plasticscm_en_work_33_form1_dev-2_commit_second_preserve_workspace_changes.png")
And Process all merges:
![plasticscm_en_work_34_form1_dev-2_commit_second_preserve_workspace_changes_process_merges.png]( "plasticscm_en_work_34_form1_dev-2_commit_second_preserve_workspace_changes_process_merges.png")
Now on Pending Changes view, as we have done a merge, we need to regenerate the binaries from the merged text versions:
![plasticscm_en_work_35_form1_dev-2_PendingChanges_regenerate_binaries.png]( "plasticscm_en_work_35_form1_dev-2_PendingChanges_regenerate_binaries.png")
Before checking in, let’s verify the resulting binary that we have regenerated:
![plasticscm_en_work_36_form1_dev-2_PendingChanges_verify_form1_merge.png]( "plasticscm_en_work_36_form1_dev-2_PendingChanges_verify_form1_merge.png")
Yeah, that’s right :-) All changes are there, so checkin now and see the Branch Explorer view:
![plasticscm_en_work_37_form1_dev-2_BranchExplorer_view.png]( "plasticscm_en_work_37_form1_dev-2_BranchExplorer_view.png")
Now we can merge the task_001 into the release (switch workspace to the release branch and merge), then merge the release into main branch and label it as “v2_0”:
![plasticscm_en_work_38_merge_task_001_into_release_into_main.png]( "plasticscm_en_work_38_merge_task_001_into_release_into_main.png")
And that’s it! We have 2 devs that have made concurrent modifications on the same form with success, and taking the task to production.
PlasticSCM - Download and configuration
PlasticSCM – Adding an existing VFP project
PlasticSCM – Working with branch per task
PlasticSCM – Working with branches with a second developer on same task
PlasticSCM – What’s next
Next: PlasticSCM – What’s next
PlasticSCM – Working with branches with a second developer on same task
You are working alone up to now, but at this point you need help to delegate some work on a second developer in the same task, what to do?.... Easy!First you create your new work branch, now you can’t keep modifying the master task branch anymore because a second developer is in and you wan’t have conflicts with both modifications. You must think on a branch as a personal directory that one and only one developer can modify directly. Always that 2 or more developers need to modify one branch, they do that using sub-branches of the task, and updating the main task only with merges, never directly.
So let’s create your dev-1 work branch, modify form1 and add 2 new controls (lblLastName and txtLastName) , save the form, generate the text files for pending changes and checkin the 3 files combo (scx/sct/sc2):
While your where doing this, dev-2 came in, created his dev-2 work branch, modified form1 and added 2 new controls (lblSex and txtSex):
So the Branch Explorer show this with both modifications, each one on a different sub-branch:
Now we need to merge both changes, and this is the best part: The first developer that merges their changes, get an automatic merge, and second developer that merge, almost surely must resolve the conflicts, so you commit first :-)
Switch to task_001 so the home icon shows there:
And now you can merge, process all merges (automatic) and commit:
And now dev-2 does the same, and process the merges, but he must resolve 3 conflicts in this case (look at the “Non automatic. User intervention needed” message on the upper-left and the “Pending non-automatic: 3/3” counter on the upper-middle). As you can see, both changes must be implemented:
So dev-2 click on top button “Mark as resolved” and find the second conflict, on which both controls code is shown. As earlier, we use the same solution and “Mark as resolved” because we need both codes:
The last conflict, in this case, is an easy one to resolve, like earlier, so same resolution:
As you can see, the counter shows 0 conflicts now, so we can click “Save & Exit”, and this finishes the text merge, but we have left the binaries. What we do with them?
That’s the easy part: we have merged the only files that can be merged, the text files that represent those binaries, so in this case the binaries must have left untouched because we are going to regenerate them in the Pending Changes view!
Now let’s bypass those binaries:
And Process all merges:
Now on Pending Changes view, as we have done a merge, we need to regenerate the binaries from the merged text versions:
Before checking in, let’s verify the resulting binary that we have regenerated:
Yeah, that’s right :-) All changes are there, so checkin now and see the Branch Explorer view:
Now we can merge the task_001 into the release (switch workspace to the release branch and merge), then merge the release into main branch and label it as “v2_0”:
And that’s it! We have 2 devs that have made concurrent modifications on the same form with success, and taking the task to production.
Index of contents:
Using FoxBin2Prg with PlasticSCMPlasticSCM - Download and configuration
PlasticSCM – Adding an existing VFP project
PlasticSCM – Working with branch per task
PlasticSCM – Working with branches with a second developer on same task
PlasticSCM – What’s next
Next: PlasticSCM – What’s next