by Sophie Engle on Jul 2013
This guide discusses some important concepts when it comes to working with SVN. Some of these concepts are explored further in the Using SVN via Command Line guide.
Your code repository on the SVN server is where your code is centrally stored, but not where you actually work on the code. For that, you need to create a working copy of your code on your local system. You checkout a working copy of your code using the svn checkout command. This will make a copy of your code repository on your local system, and SVN will watch the changes you make to this working copy. You can then use various SVN commands to keep your working copy and code repository synchronized.
SVN will automatically "watch" the files you checkout from your code repository for changes. If you add new files or directories, you need to let SVN know to watch these files too. (Unless you are using Eclipse, which knows which files to include and which temporary files to exclude from the watch list.)
You can automatically create and add a new directory to the SVN watch list by using the svn mkdir command. Otherwise, you need to use the svn add command on each file and directory you added since you last checked out or updated your code.
Any file in your working copy that is being watched will be in one of the following states:
Unchanged (i.e. no changes made in working copy) and current (i.e. there is not a newer version in the SVN repository)
Locally changed (i.e. changes have been made in working copy) and current (i.e. there is not a newer version in the SVN repository)
Unchanged (i.e. no changes made in working copy) and out of date (i.e. there is a newer version in the SVN repository)
Locally changed (i.e. changes have been made in working copy) and out of date (i.e. there is a newer version in the SVN repository)
Exactly how each SVN command works depends on the state of each file. For example, if a file is unchanged and out of date, that means your working copy has an old version of that file and a newer version is available on the code repository. In this case, you must run the svn update command to fetch/pull the latest version of the file from the repository.
If a file is instead locally changed and current, then there are new changes made in your working copy that have not yet made it to the central code repository. In this case, you must run the svn commit command to save those changes to the repository. Every time you commit files in your working copy, you create a new version of your code.
Both the svn update and svn commit commands will do nothing if your file is unchanged and current. In that case, you have the latest copy of the file from the server in your working copy and have yet to make any new changes.
If, however, you have a file that is both locally changed and out of date, you will run into a conflict. In this case, you had an old version of the file in your working copy and made changes to that file. Any attempt to run svn commit in this situation will fail. If you instead try to run svn update, SVN will attempt to merge the changes together if possible. In general, you want to avoid this situation as the clean up can be time consuming.
We have the SVN server running on the CS network. You need to interact with this server using an SVN client. You have the following options:
There are several other SVN clients available for your specific operating system. Many people running Windows prefer the free TortoiseSVN program.