SVN common error handling and solutions

This section and everyone together to learn about SVN error handling, by the common some of the SVN error problems listed in detail, here and share with you, hope that the introduction of this section of the SVN error handling will have some understanding. Let's take a look at common SVN error handling here.

SVN error Handling

Svn:couldn ' t perform atomic initialization. Interim solution: Upgrade SQLite.

Originally installed is Subversion 1.6.16 + SQLite 3.6.13, has been reported "couldn ' t perform atomic" This error, helpless under the attempt to upgrade initialization to sqlite3.6 3.7, asked The problem was solved.

Question 1: '. ' Isnotaworkingcopy. Can ' Topenfile '. Svn/entries ': The system could not find the specified path.

Answer: The reason is that the access path entered is incorrect, such as Svn://192.168.6.200/if the last write less "/", this error message will appear.

Question 2: After checkout the file, there is no SVN icon, what is going on.

Answer: Sometimes after the client checkout file, SVN System icon will not display, you can perform a "Cleanup", there will be SVN system icon.

Question 3: Why do you add a file that no one else can see or have in the version library?

Answer: The most likely reason is that you just executed "add" without "commit", so that only the local note that a file is intended to be added, but not actually added to the version library, to add to the version library must perform a "commit." The same is true for deleting files.

Question 4: "Commitfailed." ...... Youhavetoupdateyourworkingcopyfirst commit failed, the update operation needs to be performed first.

Answer: Multiple people simultaneously modify the same file, before submitting the other person has been preempted to the SVN server, causing the error; SVN error-Handling solution: Update the files in the working copy.

Issue 5: Prompt file conflict when update: "Oneormorefilesarenotaconflictedstate." ”

Answer: Multiple people at the same time modify the same part of the same file, SVN can not automatically merge, can cause this error; Workaround: Compare the files in the working copy to the server files and manually merge them.

Issue 6: "Commitfailed;filealreadyexists" commit failed, File * * already exists.

Answer: The version management system is very careful when changing the working copy on your computer. Before doing anything, it is possible to write your intentions to the log files on your computer. However, if an accidental operation is interrupted (for example, your computer crashes when a power outage suddenly happens), the log file record may be inconsistent with your final working state. A suggested solution: first copy the items to be submitted to the other directory, and then update the local file, and then put the copied files back to submit.

Question 7:workingcopy ' * * * locked. Pleaseexecutethe ' Cleanup ' command.

Solution: The Subversion client will write a local copy of the work before submitting the log, to prevent other clients to do the operation, if there is an error in the commit process, there will be an open log, to solve this problem needs to perform "cleanup" operations, sorting your computer copy of the work, Clean up the wrong logging so that you can continue the operation.

Issue 8: Error "subversionreportedanerrorwhiledoingacleanup!" when executing cleanup * * * ' isnotaworkingcopydirectory "

Answer: SVN error handling when this is the case, delete the hidden folder first. A temporary file in SVN under TMP, and then executes cleanup.

Question 9: Because the warehouse and the directory many, uses TSVN each time chooses the directory urlofrepository to have many addresses, how only then clears. Like clearing the history of the browser, in what way.

Answer: Right button->tortoisesvn->settings->saveddata, you can clear the things you want, including URL, log, window size, password caching, and so on.

Question 10: When SVN selects a directory showlog, some versions appear with only version numbers and (nodate), no other information, and what causes them.

Answer: There is a (nodate) revision that modifies files in a directory that you do not have permission to access for other people. This section describes the SVN error handling here, please pay attention to other related reports in this section.

SVN can not update the problem 2009-06-10 18:27 today with SVN found a problem, my colleague submitted the file I am dead or alive update do not come down, want to break head also did not find the reason, open the folder but unexpectedly found that the hidden folder does not function properly.

Search for a bit, it is said to be some kind of virus, the solution is to update the registry, find a download came, that is called a no language, estimated that the site does not like others from it to catch things, take down the content of a lot of content, lazy again find, tidy up, and by the way also can see what changed, You can only comfort yourself.

The problem solved, the hidden folder out, but also found SVN clean when tortoisesvn again collapsed, NND, really and I against, continue Google, Found that this is a 1.6.0 known bug, so it was updated to 1.6.2, the problem of the crash is OK, but the colleague's file is still not update.

There is no way, had to put the files of colleagues, deleted on the server, and then I submitted, and finally my colleagues and I can update the normal, the day, this is what happened, SVN sometimes have to use this. This is to toss people or help people.

No words anymore.

Postscript:

Colleagues have submitted a new document, I still can not update, crazy.

Check the server, permissions can not find the problem, so the directory checkout to other directories, and then back to the original directory, the problem is solved, carefully recalled that the version of the SVN client is not compatible with the problem caused by, Feel similar problems may be checkout again the project is the most basic solution.