CODEWITHSUNDEEP
svnversion-controlmergeconflict
jbranchaud
jbranchaud

Reputation: 6087

Understanding the history of merge conflicts in a Subversion repository

As teams work to develop software in parallel, there are situations in which the changes that the master repostitory has experienced are in conflict with the changes in your local file(s). An attempt to update your working copy to include changes from the master may then result in a merge conflict which needs to be resolved manually. After the developer has come up with a resolution to the merge conflict, they can then mark it as merged and commit the result to the master repository.

By looking through the history of a subversion repository, I can see when files were originally added, all the times they were modified, and even when particular files were deleted. I can even see what lines of code were involved in these events.

My question then is: Does the history of a subversion repository contain any information about merge conflicts that have happened throughout the development process? What about when those conflicts are resolved? I get the impression that this type of information isn't stored anywhere, but I am curious if others have thoughts or insights on this.

Upvotes: 2

Views: 547

Answers (2)

DaveShaw
DaveShaw

Reputation: 52788

No, subversion does not record that a conflict occured. It occurs when you perform an update and is resolved by the person who did the update. The only way svn knows that a revision was merged is from the merge-info property on the root folder. It will just appear as an edit because when it is resolved it is nothing more than an edit. It could be reverted, if the version from the update is a replacement for a local change.

Upvotes: 2

Kinexus
Kinexus

Reputation: 12904

No, the merge process is a client action and results in a 'merged' file that is then uploaded to the repository. The only history stored by the server would be the final action, the upload.

Upvotes: 1

Related Questions