Today, when submitting the project file to the local SVN, an error is prompted as follows:

Expiration: “global. PHP” in transaction “21-1”,
you have to update your working copy first

After running update and submitting again, the following error occurs:

Svn: commit failed (details follow): SVN: About commit: ‘global. PHP’ remains in conflict. At this point, you need to resolve the conflict (merge other people’s changes)
——————————————————————————–

For example, Sally modified sandwich.txt. Harry just changed the file in his local copy and submitted it to the server. Before submitting, Sally updated its working copy and got a 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 are 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 are in conflict, there are three things you can choose from:

Merge conflict text manually (check and modify conflict flags in files)

Overlay your work file with a temporary file

Run SVN reverse & lt; filename> To discard all changes

Once you have resolved the conflict, you need to let subversion know through the command SVN resolved. In this way, three temporary files will be deleted, and subversion will not think that the file is in conflict

$ svn resolved sandwich.txt Resolved conflicted state of ‘sandwich.txt’

Merging conflicts by hand
it’s scary to try to solve conflicts for the first time, but after a little training, it’s as simple as riding down a hill

Here is a simple example. Due to poor communication, you and your colleague Sally edited sandwich.txt at the same time. Sally submitted a modification. When you are ready to update your version, a conflict occurs. We have to modify sandwich.txt to solve this problem. First, take a look at this file:

$ cat sandwich.txtTop piece of breadMayonnaiseLettuceTomatoProvolone<& lt;& lt;& lt;& lt;& lt;& lt; . mineSalamiMortadellaProsciutto=======SauerkrautGrilled Chicken>>>>>>> . The less than, equal and greater than strings are conflict markers, not conflict data. You must make sure that these contents are deleted before the next submission. The contents in the middle of the first two groups of markers are the modifications you made in the conflict area

<& lt;& lt;& lt;& lt;& lt;& lt; . Minesalami mortadella prosciutto = = = = = = = the last two groups have a modification conflict submitted by Sally:

=======SauerkrautGrilled Chicken>>>>>>> . R2 usually you don’t want to just delete the conflict flag and Sally’s modification – she’ll be surprised when she receives the sandwich. So you should go to her office or pick up the phone and tell Sally that you can’t get the pickles you want from the Italian deli. Once you have confirmed the submission, modify the file and delete the conflict flag

Top piece of bread mayonnaise lettucetomato Provolone salami mortadella prosciutto Creole mustardbottom piece of bread now runs SVN resolved, and you are ready to submit:

$SVN resolved sandwich.txt $SVN commit – M “go ahead and use my sandwich, discarding Sally’s edits.” remember, if you feel confused when modifying conflicts, you can refer to three files generated by Subversion – including those you haven’t updated. You can also use a third-party merge tool to examine the three files

Copy to cover your working file
if you just want to cancel your modification, you can just copy the file generated by subversion to replace your working copy:

$SVN updatec sandwich.txtupdated to revision 2. $LS sandwich. * sandwich.txt sandwich.txt.mine sandwich.txt.r2 sandwich.txt.r1 $CP sandwich.txt.r2 sandwich.txt $SVN resolved sandwich.txt

$SVN reverse sandwich. Txtreverted ‘sandwich. TXT’ $LS sandwich. * sandwich.txt note that when you recover a conflicting file, you do not need to run SVN resolved

Now we are ready to submit changes. Note that SVN resolved does not need parameters like other commands we have learned in this chapter. Whenever you think a conflict has been resolved, just run SVN resolved carefully. Once you delete a temporary file, subversion will let you submit the file, even if there are conflict marks in the file

Submit you have to modify
finally! Your changes are over. You have merged all the changes on the server. You are ready to submit the changes to the repository

The SVN commit command sends all the changes to the version library. When you submit the changes, you need to provide some log information describing the changes. Your information will be attached to the revision. If the information is very short, 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, if you take writing log information as part of your work, you may want to get log information by telling subversion a file name. Use the — file option:

$ svn commit –file logmsg Sending sandwich.txt Transmitting file data . Committed revision 4.

If you don’t specify the — message or — file options, subversion will automatically start your favorite editor to edit the log information

The repository doesn’t know or care whether your modification is meaningful as a whole. It only checks whether someone else has modified the same file. If someone else has already done so, your whole submission will fail and you will be prompted that one or more files are out of date

$ svn commit –message “Add another rule” Sending rules.txt svn: Commit failed (details follow): svn: Out of date: ‘rules.txt’ in transaction ‘g’

At this point, you need to run SVN update to handle all the merges and conflicts before you try to commit

We have covered the basic work cycle of subversion, and there are many other features to manage your version library and working copies, but you can easily work with just the commands described above