Difference between svn checkout and svn update

Question

I have deployed an application using svn. Now that I have made some changes I wanted to run svn update in order to update my application.

After running svn update errors pop up. However when I remove all files (including the .svn folder) and perform an svn checkout [repourl] there are no errors.

My question is what is the difference between svn update and svn checkout [repourl] in this situation? Why does a checkout of revision 100 work but an update from revision 50 to revision 100 product errors.

If you need additional information let me know, I've tried to keep it short.

I have looked at Subversion - What are the differences between the SVN checkout and SVN update commands? but this didn't help me find an answer.

Answer 1

For better understanding, we can break [RedBean.SVNBook]: svn checkout (co) in 2 logical steps:

• Sets up (initializes) your working copy (WC): downloads from the server the SVN metadata (I'm going to explain below)
• Performs an svn update (svn up)

[RedBean.SVNBook]: svn update (up) downloads from the server (if not instructed otherwise) the latest state (called revision - which is a number that gets incremented by every modification) of the repository (based on the SVN metadata). It will also update the SVN metadata.

That's why svn checkout (svn co) is only used once (at the beginning), and from there subsequent WC updates are performed via svn up.

Since svn co creates (overwrites) the SVN metadata, and then updates the WC, it will always succeed, but since an external factor (the user) can mess up that metadata from the moment it's created, till svn up (or any other svn command as a matter of fact) takes place, svn up might fail.

SVN metadata:

• Located in the .svn folder under the root folder of your WC (older versions kept one such folder under every folder in the WC - which was messy). It's a bad idea to delete (or mess with) the .svn folder, basically your WC will become invalid; in such a situation a svn co is the only way to recover
• Contains data that SVN uses during various operations:
  • Server URL - when running a svn command that works with the server (e.g. svn up) you don't have to specify it (as for svn co) since it gets it from the metadata
  • Revision history - all the modifications that took place on every file / folder in the WC
  • Revision number - the last change / revision that was "downloaded" from the server (in the meantime the server could have advanced in revisions because other people made changes)
  • File / folder data - explained below

Your WC consists of a folder tree (contains folders and files). All that tree is also "replicated" in the SVN metadata (.svn folder) - that's why it takes up so much space. So, if you modify one of the source files in your WC, and then do a svn status (svn st) on it, SVN will detect the changes and svn diff will display them (in diff format) and this without connecting to the SVN server. Also, showing all the modification that a file suffered over time (svn log) doesn't need to connect to server.

I think it's clear now why svn co "always" succeeds. Regarding "After running svn update errors pop up", without details about the errors, I can't tell you more. Off the top of my head, I think of 2 situations that could lead to errors:

• You modified a file (or maybe more) in your WC. Someone else modified the same files (on the same lines roughly), and uploaded (svn commit) their changes to the SVN server. When you svn up, SVN doesn't know how to combine the changes (theirs and yours), so user intervention is required. This is not an error, but a conflict and happens frequently (if many people work on the same area), so it's perfectly normal. The conflict needs to be resolved (the 2 sets of changes merged together) making sure that both functionalities are preserved
• During a SVN operation (e.g. svn up), the svn process is abnormally terminated: e.g. Ctrl + C Ctrl + Break, the WC is left in an errorneous (locked) state. No further operations are allowed til it's brought back to normal (svn cleanup)