I am trying to learn basics of version control by Eric Sink - http://ericsink.com/vcbe/vcbe_usletter_lo.pdf
I am on page 22 now. I'll describe the scenario for you. 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.
1 - Harry commits the first/initial code.
2 - Sally changes it and commits.
3 - While 2 is happening, harry has made changes, but not committed.
4 - Harry commits and gets an error.
Transmitting file data .svn: Commit failed (details follow):
svn: File '/lottery.c' is out of date
5 - To fix this, harry will update his local copy using svn update.
This is where I have a problem ! The author says the output is:
lottery harry$ svn update
G lottery.c
Updated to revision 2.
But, my output is :
lottery harry$ svn update
Updating '.':
C lottery.c
Updated to revision 2.
Conflict discovered in file 'lottery.c'.
Select: (p) postpone, (df) show diff, (e) edit file, (m) merge,
(mc) my side of conflict, (tc) their side of conflict,
(s) show all options:
I am new and I don't know how to respond to this message. Is my book wrong ? Please help me. Thanks.
When you have multiple people changing the same file at once, it's very possible for both to change the same lines. This is what happened to you. Sally changes the same lines Harry was changing. When Harry did svn update, Subversion detected this, and is asking you what to do.
A word of warning: Sometimes Subversion is only looking for differences in a line between your version and their version, and not meaningful differences. For example, if the indentation of a line was changed, or spacing was different, or if you changed the line endings, Subversion will declare this as a conflict even though it probably isn't. This maybe why the book didn't find this issue, but you did. Doesn't mean you did anything wrong.
What to do? Subversion is giving you a few choices.
- postpone p: This is what I usually do with this type of situation. Subversion will embed in the file diff markers that look like this in the file:
<<<<<<< .mine
foobar
=======
fubar
>>>>>>> .rxxx
This is showing you the changes in revision rxxx (what Sally did) look like vs. the changes you have (Harry's changes). Usually, the changes are minor enough that it's pretty easy to figure out what to do.
- show diff df: This will show you the differences between your changes (Harry's) and what's in the other revision (Sally's). It basically shows you the diff markers.
- edit e: You can edit the merge conflict as you do the merge instead of waiting till later.
- merge m: Not too sure what this does. You're doing the merge right now, so this doesn't make too much sense.
- their side of conflict tc: Accept what Sally did in order to resolve the conflict. You probably have to redo your changes, but at least you're considering Sally's changes.
- my side of the conflict mc: The most dangerous scenario because you're completely ignoring Sally's changes. Sally did a fix, and you're possibly unfixing it. When the release comes out, and Sally's fix isn't in it, you will be blamed for removing the change. So, why do you do this? Because you already looked at the changes, and realized the conflict really wasn't much of a conflict. It was a change in indentation or something similar. Or you called a variable
increment and Sally called it counter.
As I said, I usually do a postpone, let my update finish, then handle the problems.
Once you fix the problem, you do a svn resolved on that file to let Subversion know you've fixed the conflict.
There are further choices -- for example, you can launch a third party diff/merge tool to handle the conflict.
For more information, take a look at the Subversion on line manual about resolving merge conflicts.
If you select the s option it will show you:
(e) edit - change merged file in an editor
(df) diff-full - show all changes made to merged file
(r) resolved - accept merged version of file
(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict - accept my version for all conflicts (same)
(tc) theirs-conflict - accept their version for all conflicts (same)
(mf) mine-full - accept my version of entire file (even non-conflicts)
(tf) theirs-full - accept their version of entire file (same)
(p) postpone - mark the conflict to be resolved later
(l) launch - launch external tool to resolve conflict
(s) show all - show this list
Use dc to view the confilicts then you can decide on the best option to use
The "G" indicates that the file was modified by somebody else, but the modifications that person did were in a different part of the file, so SVN could merge it for you without asking for help.
The "C" indicates that not only was the file modified by somebody else, but their changes were to the same lines you also changed, so SVN doesn't know what to do. Now it's YOUR job to do the merge.
You probably didn't do anything wrong, and the book isn't wrong, they just left out the detail on what the specific changes were, apparently.
