Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

Eclipse Workbench User Guide
Previous Page Home Next Page

Resolving conflicts

When updating or committing you may encounter conflicts. A conflict occurs when you have locally modified a resource for which a more recent revision is available in the branch in the repository. Specifically, the branch will contain a revision newer than the base revision of your resource. In this situation you can choose to do one of the following:

  • You can take the change from the branch, discarding your local work. This could occur if you have made unintended changes locally, or if you realize that the revision in the repository is better than yours. Overwriting your local changes should be done with caution since you are in essence throwing work out.
  • You can commit your change, subsuming the revision in the repository. This should be done with great caution since you are in essence throwing away someone else's work. In particular, the change you are overwriting may have other dependencies in the branch (for example there may be other incoming changes which depend on the conflict).
  • You can merge your work and the repository resource, saving locally the merged resource. You may then later choose to commit this merged result.

Typically, you will want to take the third option, that is to merge, because of the loss of work issues with the other two choices.

Manually merging changes

The Synchronize View indicates those resources which are in conflict with the branch. For a given resource in conflict, typically you will want to merge your changes with changes in the branch's resource.

For example, let us assume that both you and another team member have modified the same html page. Opening that resource from the Synchronize view will display a comparison of the local resource and the branch revision. By cycling through and merging the individual changes, you can decide for each change whether to accept the incoming change, reject it, or merge it with your local changes. When you are finished merging, you save your changes. This overwrites your local resource with the result of the merge. You can subsequently commit this merged resource.

Tip: When merging changes, it is often convenient to be able to distinguish which files you have completed merging. When you're done merging a file, you can pick Mark as Merged from the context menu. This will change the status of the file from being a conflict to being an outgoing change.

You can merge differences in the Synchronization view on two levels:

  • Whole Document - In the Synchronize view, open the resource that you want to merge in a Compare editor. In the Compare editor, click the Copy all non-conflicting Changes from Right to Left button to copy all non-conflicting changes. Conflicting changes will have to copied individually.
  • Current Change - In the Text Compare editor, either use the Go to Next Difference and Go to Previous Difference buttons to navigate to the change that you want to merge, or simply click in either source pane somewhere in the desired change difference fragment. Click the Copy current change from right to left button as needed to overwrite the highlighted fragment either with the corresponding modification in the branch.

Auto merging changes

It is also possible to have your changes automatically merged for you. For any resource marked as ASCII, performing a Team > Update will automatically merge into your local resource differences with the branch resource. This works fine provided there are no lines with conflicting changes. If there are, CVS inserts special markup in the file to indicate those lines which could not be merged.

Updating from within the Synchronization view works a bit differently. In the case of a conflict, Update will only process files whose contents contain no conflicts. Files that have content conflicts will be skipped and left in the Synchronize view as conflicts.

 Related concepts
Team programming with CVS
Synchronizing with a CVS repository
Three way comparisons

Related tasks
Synchronizing with the repository
Updating
Committing
Merging from a branch
Comparing resources
Merging changes in the Compare editor

Related reference

Compare editor


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire