The process of SVN

SVN is a centralized system, so you have one central repository. The first step is to create the repository
that your code will sit in. This will either be on your local network, a remote server, or third-party service
that offers repository hosting. This is, however, still classified as a remote repository, it just happens to be
hosted on a server you don’t fully control. Once your repository is created, you then do a “checkout” of the
code to a folder on your local machine. This is a copy of the remote code, which you can make changes to
as need be, without affecting the code in the repository.
Having one main repository allows for multiple people to take a copy of the same code base and
collaborate on the same code project. Now that there is a local version of the repository on your machine,
you can make any needed changes to it, including adding new files. Any number of files can be added to
the repository by using a number of methods, but until those changes are pushed to the main repository
they are only available to you. Once you have made any needed changes to the code or added any new
files, you would then “commit” the code to the repository. When you commit any files, whether they are
existing or new, you get the option to add a message. These can come in very, very useful when you
come to revert a file and wonder why it was committed in the first place. There is always the option to use
a message with no meaning or relevance at all, such as on http://whatthecommit.com; however, that
doesn’t help at all. Having useful commit messages is an asset to anybody using version control, and
getting into the habit of using them should be learned as early as possible. Once your message has been
added, the code will be merged with the existing code in the repository. If, however, SVN detects that
someone else has made a change to a file you’re about to commit, it will stop it and tell you to update to
the latest version of the code. This, of course, means you check for any changes to the central repository
compared to your local version. If it detects that you need to download new files, or new versions of files, it
will do that for you. If you do add new files and they are successfully committed, from now on, any user
that updates from the repository will get the new files. Although putting it into words can make it seem
complicated, it’s actually quite simple. Have a look at Figure below to see it in a nice visual format.

Of course, that only handles pushing updates and new files. What If something goes wrong and you need
to get back a previous version of a file your working on? Well, you can revert your local version of a file to
the version currently in the repository, or an even older version than the current one.
All of these actions can easily be managed with a SVN GUI on any of the main operating systems. In most
cases updating, committing, and reverting can be done by one or two clicks of a button, which makes it
very simple to use and manage, and also explains why so many designers and low-end developers like it
for its simplicity and ease of use.

Comments