3

Me and my friend need to develop a project parallely. how to do this?

I created two branch worked on each leaf. Tried to merge the leaves but getting conflict error for edited file. What is the way to merge them?

I would like to know if it possible to have 2 leaves in a single branch? If so then how to create a new leaf in addition to the default leaf.

Dinesh
  • 1,825
  • 5
  • 31
  • 40

1 Answers1

6

Each branch has one leaf at any time. These represent the most recent state of the repository from the perspective of each branch. As your post mentions, branches are used to afford parallel developments within the repository. They are also created automatically (called a "fork" in such a case) to prevent two commits to same branch when each commit has the same immediate ancestor... allowing this would be just like having multiple leaves on the same branch.

To create a new branch of development, one opens a fossil repo and executes a command like:

fossil branch new some_feature trunk

Complete example

For the sake of example, I quickly created a new repository and added a single file to the trunk (the only branch initially), file.txt. The initial contents of my example file are:

here
is
a
file

After committing the added file with the comment, "create baseline", I created a development branch for a new feature called "some_feature" based on the current state (aka the leaf) of the trunk branch...

fossil branch new some_feature trunk

Now there are two branches, trunk and some_feature. Creating the branch does not change my working branch, so I am still in trunk. Then I edited the baseline file to:

here
is
a
file
folder

...adding "folder" to the end. Then I committed the change to trunk with the comment, "modification on first branch... trunk. Then I switched development to the some_feature branch...

fossil co some_feature

From this second branch, I also edited the last line of the baseline file:

here
is
a
file
reader

...adding "reader" to the end. Then I committed the change to some_feature with the comment, "modification on second branch... some_feature".

To merge development, you chose the branch you want to merge changes into. In this case, I will merge the feature branch changes into the trunk. To do this you must first checkout the destination branch for the merge... in my case, trunk.

fossil co trunk

Then, I merge in the change from the specific commit of the other branch. In my case, I'll use the leaf of that branch:

fossil merge some_feature

    MERGE file.txt
    ***** 1 merge conflicts in file.txt
    WARNING: 1 merge conflicts
    "fossil undo" is available to undo changes to the working checkout.

This leaves me with four files now in my working directory instead of one. No new commit/checkin has actually made it back to the repository proper. The four files are: file.txt, file.txt-baseline, file.txt-merge, and file.txt-original. "file.txt-baseline" is the file as it existed in the most recent common ancestor of the merging branches. "file.txt-original" is the file as it existed in the target brach, in my case, trunk, just before the merge. "file.txt-merge" is the file as it existed in the branch you were merging from, in my case, some_feature. Finally, "file.txt" contains the contents of the baseline file with conflicting changes from the original and merge files annotated so you can decide how to deal with the differing contents.

In my case the generated conflicts file, "file.txt" looked like this:

here
is
a
file
<<<<<<< BEGIN MERGE CONFLICT: local copy shown first <<<<<<<<<<<<<<<
folder
======= COMMON ANCESTOR content follows ============================
======= MERGED IN content follows ==================================
reader
>>>>>>> END MERGE CONFLICT >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

Until the merge conflict annotations are removed from the file, fossil will not let you commit (or it will at least warn against it). Otherwise, you would make a commit with message, such as, "merged some_feature into trunk".

For reference, here is the event history diagram as provided by fossil for this example:

Fossil generated event history for my example project

Amos
  • 286
  • 2
  • 6
  • How to remove the merge conflict annotations? Does it needs to be done manually? If so when 2 developers are working there will lot of merge conflict annotations to resolve manually. – Dinesh Mar 04 '14 at 04:37
  • Merging is extremely common, but it does not always mean it involves dealing with conflict annotations. Whenever two branches of development must come together, you merge. The "merge" operation tells fossil to combine the states of the target and designation branches as best it can. Only when there are modifications to the same parts of a file will explicit conflicts arise that require you to deal with the annotations. Otherwise, fossil just puts all the changes together. That doesn't mean your code will work... you'll always need to verify that before you commit, annotations or not. – Amos Mar 05 '14 at 01:44
  • And, yes, you have to remove the annotations manually, but that is easy... they are just text. The more challenging part (which is not always that challenging, really) is getting the conflicting code to work as each party intended after you revisions. The best thing to do is ensure a file architecture that allows team members to work on their respective parts without touching the same files... at least not the same parts of the same files. No matter what, though, when you merge, you have to do a bit of testing to ensure everything works as expected before committing. – Amos Mar 05 '14 at 01:50