When you have finished the changes on a certain branch, you will
often want to incorporate them into the file's main line of development
(the trunk). This is not a trivial operation, because development might
also have proceeded on the trunk, so that you must merge the
changes into a file that has already been changed otherwise. VC allows
you to do this (and other things) with the
C-x v m (
vc-merge) takes a set of changes and merges it
into the current version of the work file. It firsts asks you in the
minibuffer where the changes should come from. If you just type
<RET>, Emacs merges any changes that were made on the same branch
since you checked the file out (we call this merging the news).
This is the common way to pick up recent changes from the repository,
regardless of whether you have already changed the file yourself.
You can also enter a branch ID or a pair of revision IDs in the minibuffer. Then C-x v m finds the changes from that branch, or the differences between the two revisions you specified, and merges them into the current revision of the current file.
As an example, suppose that you have finished a certain feature on branch 1.3.1. In the meantime, development on the trunk has proceeded to revision 1.5. To merge the changes from the branch to the trunk, first go to the head revision of the trunk, by typing C-u C-x v v <RET>. Revision 1.5 is now current. If locking is used for the file, type C-x v v to lock revision 1.5 so that you can change it. Next, type C-x v m 1.3.1 <RET>. This takes the entire set of changes on branch 1.3.1 (relative to revision 1.3, where the branch started, up to the last revision on the branch) and merges it into the current revision of the work file. You can now commit the changed file, thus creating revision 1.6 containing the changes from the branch.
It is possible to do further editing after merging the branch, before the next check-in. But it is usually wiser to commit the merged revision, then lock it and make the further changes. This will keep a better record of the history of changes.
When you merge changes into a file that has itself been modified, the changes might overlap. We call this situation a conflict, and reconciling the conflicting changes is called resolving a conflict.
Whenever conflicts occur during merging, VC detects them, tells you about them in the echo area, and asks whether you want help in merging. If you say yes, it starts an Ediff session (see).
If you say no, the conflicting changes are both inserted into the file, surrounded by conflict markers. The example below shows how a conflict region looks; the file is called ‘name’ and the current master file revision with user B's changes in it is 1.11.
<<<<<<< name User A's version ======= User B's version >>>>>>> 1.11
Then you can resolve the conflicts by editing the file manually. Or
you can type
M-x vc-resolve-conflicts after visiting the file.
This starts an Ediff session, as described above. Don't forget to
commit the merged version afterwards.
If there is more than one conflicted file in a merge, type M-x vc-find-conflicted-file after resolving the conflicts in each file. This command visits the next conflicted file, and moves point to the first conflict marker in that file.blog comments powered by Disqus