Step by Step: Version Control with Fossil Part 4

PART 4 of 4

Working together with other, there are a chance to have version conflict.
For instance, while both Alice and Bob are in revision 3, Bob has commit his code to revision 4. Alice, which is now offline, also commit to revision 4.
Thus, there will be a conflict on revision 4. Both Alice and Bob can commit and push their code in to the remote repository at the same time (using –allow-fork). However, The timeline will be ended up with separate commit which is need to be merged back again.

Sample of forking

Above is the phenomena called "Forking". The history has to be separated and merged without any reason. Forking is the problem of every revision control system. Each revision control has they own technique to deal with forking.

• SVN will not accept forking and forces the one who commit later to update his/her local repository before committing the new one.
• Git has "rebase" command that will manipulate the history and rearrange those forking timeline. The forking is fixed, but end up with lied history.
• Mercurial accept forking as the way of concurrent workflows. However, Mercurial still provide tools for local repository to rearrange his or her history before pushing to remote repository.
• Fossil use auto-sync to reduce the chance of having this issue. Fossil also provide “stash” which will move you changes to the temporary storage so that you can update the code from remote repository. Then, move you change back from stash.

By default, Fossil will not allow forking commit (this is the same behavior as SVN)

If the forking already occur, you can merge those separated main branch via “fossil merge”. The way to merge forking branch is the same as the way to merge normal branches. See the next step for how to merge branching

 

 

 

 

Brunching (Forking Done Right)

Brunching is similar to the forking. The different is that a brunch will contains a name. This serve as a document for what was done in this brunch. With brunching, the timeline is easy to be investigated on the future. One can easily switch between the adding branch or trunk.

Alice is now facing with task that will take time to finish. Alice don’t want any artifacts from Bob to interfere her work.  So, she decide to create a brunch.

Let’s continue from the last walkthrough. Open the AliceDocument and create a branch with the following command.

C:\Tutorial\AliceDocument>fossil branch * trunk C:\Tutorial\AliceDocument>fossil branch new TimerLogicImplementation trunk New branch: 4f41637962778bd9283584c8a7fc44029a0f0829 C:\Tutorial\AliceDocument>fossil branch   TimerLogicImplementation * trunk C:\Tutorial\AliceDocument>fossil checkout TimerLogicImplementation build.xml manifest.mf nbproject/build-impl.xml nbproject/configs/Run_as_WebStart.properties nbproject/configs/Run_in_Browser.properties nbproject/genfiles.properties nbproject/jfx-impl.xml nbproject/project.properties nbproject/project.xml src/timer/CountDownTimer.java src/timer/FXMLDocument.fxml src/timer/FXMLDocumentController.java src/timer/Timer.java test/CountDownTimerTest.java C:\Tutorial\AliceDocument>fossil branch * TimerLogicImplementation   trunk

The command “fossil branch” is to display all the branches in this repository. The command “fossil branch new TimerLogicImplementation trunk” tell the fossil to create a branch named TimerLogicImplementation from trunk.

Commit Code to Trunk

Bob still continue doing his work on UI logic. Copy and replace code from Iteration/Iteration3 to the BobDocument. Start the fuel. Click File>Open. Navigate to BobDoument\_Fossil_. Click refresh to see the changes. Then, commit the changes.

A code commited from Bob

 Bob's timeline will be displayed as follows.

A code committed to trunk

 

Commit code to branch

Alice finished her work and are committing changes to the branch. Let back to AliceDoument. Similar to what we did on Bob, copy and replace code from Iteration/Iteration4 to the AliceDoument. Start the fuel. Click File>Open. Navigate to AliceDoument \_Fossil_. Click refresh to see the changes. Then, commit the changes.

A code committed from Alice

Since Alice has checked out the TimerLogicImplmentation branch, her artifacts will be committed to that branch.

A code committed to branch

Merge the code

Both Bob and Alice has done their own works. Now, it is the time to integrate their work. Alice will merge the code from main branch.

1. Go to the Alice Command’s prompt and run merge command as follow.

C:\Tutorial\AliceDocument>fossil merge trunk UPDATE src/timer/FXMLDocumentController.java MERGE src/timer/CountDownTimer.java ***** 1 merge conflicts in src/timer/CountDownTimer.java WARNING: 1 merge conflicts  "fossil undo" is available to undo changes to the working checkout.

2. Start the fuel. Click File>Open. Navigate to AliceDoument \_Fossil_. Click refresh to see the changes.

A merge conflicted file show

3.As you can notice, there are a file mark as conflicted. Also, some files (-baseline -merge -original) are generated. It happens because both Alice and Bob edit the code on the same file (and same line). This conflicted has to be resolved before commit. To resolve the conflict, you can simply remove all the
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Which are the mark tag for the conflict.
In this tutorial we will use the graphical merge tools.

4.Open the TortoiseGitMerge and select the files as belows

Prepare file for merge tool

After click OK, you should see these windows.

Merge window

On the conflict area, select the code from Alice.

Use code from Alice

Conflict has been resolved

 You will notice that the conflict has been resolved.

5. Click “Save As” and choose “Save Buttom File As”. Then navigate to the [YourPath]\AliceDocument\src\timer\ CountDownTimer.java. Finally, commit the artifacts.

C:\Tutorial\AliceDocument>fossil commit

6. Now, test the result of merging code then update all change to trunk.

C:\Tutorial\AliceDocument>fossil checkout trunk build.xml manifest.mf nbproject/build-impl.xml nbproject/configs/Run_as_WebStart.properties nbproject/configs/Run_in_Browser.properties nbproject/genfiles.properties nbproject/jfx-impl.xml nbproject/project.properties nbproject/project.xml src/timer/CountDownTimer.java src/timer/FXMLDocument.fxml src/timer/FXMLDocumentController.java src/timer/Timer.java test/CountDownTimerTest.java C:\Tutorial\AliceDocument>fossil merge TimerLogicImplementation UPDATE src/timer/CountDownTimer.java UPDATE test/CountDownTimerTest.java  "fossil undo" is available to undo changes to the working checkout. C:\Tutorial\AliceDocument>fossil commit C:\Windows\notepad.exe "./ci-comment-A88C89562BB2.txt" New_Version: 26d09174350193b4a4cf484f3c28c4fbac89d88e

The timeline should display as follows

All merge has been updated to trunk

Note that the step of merge that we have done are
1. (Alice) Checkout branch
2. (Alice) At branch, merge to trunk
3. (Alice) At branch, Fix conflict and commit
4. (Alice) At branch, test the result
5. (Alice) Checkout trunk
6. (Alice) At trunk, merge from brunch.

The benefit of merging to bunch before update the truck is that, in the step 4, QA\tester can also checkout the code from merged brunch and test the correctness of integration. If you want to simplify the merging steps, it can be done in this orders.
1. (Alice) Checkout trunk
2. (Alice) At trunk, merge to branch
3. (Alice) At trunk, Fix conflict and commit

Finally, go to BobDocument and run “update” to retrieve all the new artifacts from the server.