
It was a change in indentation or something similar. So, why do you do this? Because you already looked at the changes, and realized the conflict really wasn't much of a conflict. When the release comes out, and Sally's fix isn't in it, you will be blamed for removing the change. Sally did a fix, and you're possibly unfixing it. my side of the conflict mc: The most dangerous scenario because you're completely ignoring Sally's changes.You probably have to redo your changes, but at least you're considering Sally's changes. their side of conflict tc: Accept what Sally did in order to resolve the conflict.You're doing the merge right now, so this doesn't make too much sense. edit e: You can edit the merge conflict as you do the merge instead of waiting till later.show diff df: This will show you the differences between your changes (Harry's) and what's in the other revision (Sally's).

Usually, the changes are minor enough that it's pretty easy to figure out what to do. This is showing you the changes in revision rxxx (what Sally did) look like vs. Subversion will embed in the file diff markers that look like this in the file:

#Subversion conflict how to
I am new and I don't know how to respond to this message. (mc) my side of conflict, (tc) their side of conflict, Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
#Subversion conflict update
This is where I have a problem ! The author says the output is: lottery harry$ svn updateīut, my output is : lottery harry$ svn update svn: Commit failed (details follow):ĥ - To fix this, harry will update his local copy using svn update. Two users on the same computer, harry and sally are working on a file called lottery.c which is stored in a repo called lottery.ġ - Harry commits the first/initial code.ģ - While 2 is happening, harry has made changes, but not committed.Ĥ - Harry commits and gets an error. I am trying to learn basics of version control by Eric Sink.
