SVN occurrence of the exclamation mark file conflict resolution

SVN occurrence of the exclamation point file conflict Resolution This method is I saw on the net, at that time I also encountered SVN file conflict, after watching the feeling is good, so the collection to share with you as follows: The resolution version of the conflict command. After the conflict is resolved, you need to use SVN resolved to tell the subversion conflict resolution to commit the update. When a conflict occurs, Subversion saves all versions of the target file in work copy (the last updated version, the currently obtained version, that is, the version that was submitted, the version of the update, the target file.) Suppose the filename is sandwich.txt, and the corresponding filename is: Sandwich.txt.r1, SANDWICH.TXT.R2, Sandwich.txt.mine, Sandwich.txt. Also marks changes from different users in the destination file. Resolution of conflicts:-Manual resolution: When a conflict occurs, manually update the target file after communicating with other users. Then execute SVN resolved filename to dissolve the conflict, and finally commit. -Discard your own updates and use other people's updates. Overwrite the target file with the latest obtained version, execute SVN resolved filename and submit. -Discard your own updates, use SVN revert, and then submit. You do not need to use SVN resolved in this way. For the SVN resolved command to be very careful, it must be very certain that the conflict has been resolved before it can be used. Failure to do so will cause subversion to resolve the conflict and make the code base incorrect. Conflict resolution Details: http://svnbook.subversion.org.cn/1.2/svn.tour.cycle.html#svn.tour.cycle.resolve Resolving conflicts (merging others ' modifications) we can use SVN Status-u to predict the conflict when you run SVN update some interesting things happened: $ svn update U INSTALL G README C bar.c Updated to revision 46. You and g do not need to care, the file is clean accept the change of version library, the document marked as U indicates that the local did not modify, the file has been updated according to the version library. G marked Merge, marked Local has been modified, and the repository does not overlap with the place, has been merged. But C means conflict, the changes on the server conflict with your changes, you need to manually solve. When a conflict occurs, there are three things that can help you notice this situation and solve the problem: subversion prints the C tag and marks this file as conflicting. If SubversIon that this file is merged, it will place the conflict tag-a special horizontal line separating the "two sides" of the conflict-the part of the visual description in the file that overlaps (subversion uses the Svn:mime-type attribute to determine whether a file can use context, and merges the behavior base, More information can be seen in the "Svn:mime-type" section. For each conflicting file, Subversion places three additional unpublished files into your working copy: Filename.mine files before you update, no conflicting flags, just the content of your latest changes. (If subversion does not think the file can be merged, the. mine file is not created because it is the same as the working file.) Filename.roldrev This is your previous base version of the update operation, which is the version you have not changed since you last updated. Filename.rnewrev This is the version that your subversion client has just received from the server, and this file corresponds to the head version of the version library. Here Oldrev is yours. The revision number in the SVN directory, Newrev is the version number of the head in the version library. For example, Sally modified Sandwich.txt,harry just changed the file in his local copy and submitted it to the server, and Sally updated its working copy before submitting it to the conflict: $ svn update C Sandwich.txt Updated to Revision 2. $ ls-1 sandwich.txt sandwich.txt.mine sandwich.txt.r1 sandwich.txt.r2 in this case, Subversion will not allow you to submit sandwich.txt until your three temporary files have been deleted. $ svn commit--message "Add a few more things" Svn:commit failed (Details follow): svn:aborting commit: '/HOME/SALLY/SVN -work/sandwich.txt ' remains in conflict if you encounter a conflict, three things you can choose: "Manually" merge conflicting text (check and modify conflicting flags in the file). Overwrite your working file with a temporary file. Run SVN revert to discard all modifications. Once you have resolved the conflict, you need to command SVN resolved to let subversion know, which will delete the three temporary files, subveRsion would not have thought the file was in a state of conflict. [5] $ SVN resolved sandwich.txt resolved conflicted state of ' sandwich.txt ' manual merge conflict The first attempt to resolve the conflict was scary, but after a bit of training it was simply like riding down a car downhill. Here is a simple example, because of bad communication, you and colleagues Sally, while editing the sandwich.txt. Sally submitted the change, and when you are ready to update your version, the conflict has occurred and we have to modify the sandwich.txt to solve the problem. First, take a look at this file: $ cat sandwich.txt top piece of bread mayonnaise lettuce tomato provolone <<<<<<< mine S Alami mortadella prosciutto ======= Sauerkraut Grilled chicken >>>>>>>. r2 Creole Mustard Bottom Piec E of bread less than, equals and greater than string are conflicting markers, not conflicting data, you must make sure that the content is deleted before the next submission, the first two sets of signs in the middle of the conflict zone you have made changes: <<<<<<<. Mine salami mortadella Prosciutto ======= between the two groups was Sally submitted by the change conflict: ======= Sauerkraut Grilled Chicken gt;>. R2 usually you don't want to just delete conflict signs and Sally's modifications-when she gets a sandwich, it's very surprising. So you should go to her office or pick up the phone and tell Sally that you can't get the kimchi you want from the Italian deli. [6] Once you have confirmed the submission, modify the file and delete the conflicting flag. Top piece of bread mayonnaise lettuce tomato provolone salami mortadella prosciutto Creole mustard Bottom piece of bread In running SVN resolved, you are ready to submit:$ SVN resolved sandwich.txt $ svn commit-m "go ahead with" my sandwich, discarding Sally ' s edits. "Remember, if you change the conflict and you feel confused, you can Test subversion generated three files-including files that you did not update. You can also use a Third-party merge tool to test these three files. Copy overwrite your working file if you just want to cancel your changes, you can simply copy subversion to replace your working copy of the file you generated: $ svn update C sandwich.txt Updated to revision 2. $ ls sandwich.* sandwich.txt sandwich.txt.mine sandwich.txt.r2 SANDWICH.TXT.R1 $ cp sandwich.txt.r2 Sandwich.txt $ svn res Olved sandwich.txt bet: Use svn revert if you get a conflict, after checking you decide to cancel your own changes and edit again, you can restore your modifications: $ svn revert Sandwich.txt reverted ' Sandwich.txt ' $ ls sandwich.* sandwich.txt Note that when you recover a conflicting file, you do not need to run SVN resolved again. Now that we are ready to submit the changes, note that SVN resolved does not need arguments as much as any other command we've learned in this chapter, and that when you think you've resolved a conflict, you just have to run SVN resolved,-once you delete the temporary file, subversion will let you submit the file, Even if there are conflicting flags in the file. Submit you have to revise the last. Your modifications are over, you have merged all the changes on the server and you are ready to submit the modifications to the repository. The SVN commit command sends all changes to the version library, when you submit a change, you need to provide some log information describing the changes, your information will be attached to this revision, and if the information is brief, you can use the--message (-m) option on the command line: $ svn Commit- Message "Corrected number of cheese slices." Sending Sandwich.txt transmitting file data. Committed Revision 3. However, asIf you write log information as part of your job, you might want to get log information by telling subversion a filename, using the--file option: $ svn commit--file logmsg sending Sandwich.txt Transmitting file data. Committed Revision 4. If you do not specify a--message or--file option, Subversion automatically launches your favorite editor (see the Editor-cmd section of the "Config" section) to edit the log information. Tip If you use the editor to write log information when you want to cancel the submission, you can directly turn off the editor, do not save, if you have done save, simply delete all the text and save it again. $ svn commit waiting for Emacs ... Do Log message unchanged or not specified a) bort, c) ontinue, E) dit a $ version library do not know nor care about your modifications as a whole is meaningful, it only checks if someone else has modified the same file, if others Already done, your entire submission will fail and prompt you that one or more files are obsolete: $ svn commit--message "Add another rule" sending Rules.txt Svn:commit failed (detail s follow): Svn:out of Date: ' Rules.txt ' in transaction ' G ' Now you need to run SVN update to handle all the merges and conflicts before you try to submit. We've covered the basic work cycle of subversion, and there are many other features that can manage your repository and work copy, but you can easily work with just the commands described earlier. [3] Of course nothing was deleted in the repository-it just disappears in the head of the version library, and you can check out (or update your work copy) the previous revision of your delete operation to retrieve everything. [4] Subversion uses the built-in difference engine, which is exported by default to a uniform difference format. If you expect different output formats, you can use--diff-cmd to specify an external difference program, and pass other parameters through--extensions, for example, look at the difference between the local file foo.c, and ignore the space modification, you can run SVN diff-- Diff-cmd/usR/bin/diff--extensions '-BC ' foo.c. [5] You can also manually delete these three temporary files, but will you do it yourself when subversion will do it for you? That's what we think. [6] If you ask them, they have a good reason to take you to the rails outside the city. How to reduce the complexity of conflict resolution:-When the work is completed (i.e., after the program is written, the unit test passes) as soon as possible, frequent submissions/updates can reduce the probability of conflict occurrence and the complexity of resolving conflicts when they occur. -If the conflict occurs frequently, it is necessary to find out why. -Write a clear message at the time of submission. Easy to find the reason for the update later, after all, as time goes by, the memory will become blurred.