April 25, 2019

Version Control For Beginners: Getting Started With Subversion - page 2

Setting Up a Repository

  • February 9, 2009
  • By Juliet Kemp

It's good practice to get into the habit of updating your working copy (with the command svn update) before performing a commit. If someone else has made changes in the repository, the update will merge those updates with your working changes. If there are places where Subversion can't manage an automatic merge ��� say both you and your colleague have changed the same lines ��� you'll be given the opportunity to interactively resolve the conflict.

Alternatively, you can hit p to postpone the resolution, and then resolve it later. Edit the file in your working copy to fix the problem, then use

svn resolve --accept working conflictfile.txt
to tell Subversion to resolve the conflict using that working file. You won't be allowed to commit until after you've done this. (Check the docs for other options that this command accepts.) This process is especially important when you're writing code and a conflict could cause the code to break!

You should also always check the status of your changes before committing them, with svn status. This gives output showing filenames with various codes. Important codes are: ?, indicating a file that isn't under version control (so you want to svn add it); C, indicating a conflict that must be resolved; M, indicating that a file has been modified; and A and D, indicating files scheduled to be added and deleted, respectively.

To examine your changes more closely, use svn diff. With no options, this will print out a unified diff of all your changes.

Updating Files

Editing existing files and committing those changes works in exactly the same way as an add but without the add filename step ��� just svn update; svn commit.

Deleting, copying, and moving files

If you delete a file locally but not in the repository, the next time you update, you'll get a brand new checked-out copy of it (because Subversion will assume that you deleted it accidentally). Instead, use:

svn delete filename
svn update
svn commit
svn delete doesn't delete the file from the repository history, just from the current version: If you ran a new checkout of the project, you wouldn't get that file, but you could still revert to an old version of it.

Similarly, you should use the svn move and svn copy commands, rather than mv and cp, to move and copy files.

Further steps

A remote repository works in the same way as the local repository used above ��� just provide the full remote path at first checkout.

The svnlook tool allows you to examine various aspects of the repository, and svnadmin allows you to administer it. It's straightforward to split, merge and branch repositories, as projects grow and change.

An incredibly useful feature of Subversion is that you can set up scripts to run automatically on various actions ��� most often, pre-commit or post-commit. So you can force unit tests to be run before committing, send email on commit, or anything else you can write a script for! Again, check the docs for details.

The free online SVN Book provides excellent documentation for all of this.

Subversion really is incredibly easy to start using. It's well worth the minimal effort involved for the advantages that change-tracking provides.

Article courtesy of ServerWatch.com

Most Popular LinuxPlanet Stories