Checkout a repository

Use the co or checkout command to pull the repo directory from the remote SVN server.

Checkout the remote app_visit repository to the local /opt directory:

svn co https://svn.rap.ucar.edu/svn/app_visit/ /opt

Sometimes SVN login may default to your machine name. You can force the user with the --username flag:

svn co --username your_username https://svn.rap.ucar.edu/svn/app_visit/ /opt

Get the status of a repo

svn status

Update local, get (pull) code from the server

svn update
svn up

Add new files and directories

With SVN, new files and directories must be added to the repo using add.

Add a new file:

svn add file_name

Add all new (except ignored) files under a specified directory tree:

svn add --force path/to/dir

Delete files and directories

NOTE: Do not delete files and directories unless you use the svn delete command.

svn delete myfile

Rename or move files and directories

NOTE: Do not rename or move files or directories unless you use the svn mv command.

Commit local changes to the repo

From within the repo:

svn commit -m 'Your informative commit message.'

Commit a specific repo:

svn commit path/to/local/repo/dir -m 'Your informative commit message.'

Set an “ignored” directory:

To set the ignore property for the directory _local_assets:

svn propset svn:ignore _local_assets .

To check what properties are set:

svn proplist

To see the value of svn:ignore:

svn propget svn:ignore

To undo ignore and delete properties previously set:

svn propdel svn:ignore

SVN Branching, Merging and Releasing

• https://articles.assembla.com/en/articles/960444-branching-and-tagging-in-svn
• http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
• https://stackoverflow.com/questions/345683/svn-creating-trunk-directory-on-existing-repository

Branches

Branches protect the source code from potentially destabilizing changes.

Subversion has no internal concept of a branch—it knows only how to make copies. When you copy a directory, the resultant directory is only a “branch” because you attach that meaning to it. You may think of the directory differently, or treat it differently, but to Subversion it’s just an ordinary directory that happens to carry some extra historical information. Because of this copy mechanism, Subversion’s branches exist as normal filesystem directories in the repository. This is different from other version control systems, where branches are typically defined by adding extra-dimensional “labels” to collections of files. The location of your branch directory doesn’t matter to Subversion. Most teams follow a convention of putting all branches into a /branches directory, but you’re free to invent any policy you wish.

• Developers commit all new work to the trunk. Day-to-day changes are committed to /trunk: new features, bug fixes, and so on.

• The trunk is copied to a “release” branch. When the team thinks the software is ready for release (say, a 1.0 release), /trunk might be copied to /branches/1.0.

• Teams continue to work in parallel. One team begins rigorous testing of the release branch, while another team continues new work (say, for version 2.0) on /trunk. If bugs are discovered in either location, fixes are ported back and forth as necessary. At some point, however, even that process stops. The branch is “frozen” for final testing right before a release.

• The branch is tagged and released. When testing is complete, /branches/1.0 is copied to /tags/1.0.0 as a reference snapshot. The tag is packaged and released to customers.

• The branch is maintained over time. While work continues on /trunk for version 2.0, bug fixes continue to be ported from /trunk to /branches/1.0. When enough bug fixes have accumulated, management may decide to do a 1.0.1 release: /branches/1.0 is copied to /tags/1.0.1, and the tag is packaged and released.

• This entire process repeats as the software matures: when the 2.0 work is complete, a new 2.0 release branch is created, tested, tagged, and eventually released. After some years, the repository ends up with a number of release branches in “maintenance” mode, and a number of tags representing final shipped versions.

Creating a branch is simple. All you need to do is make a copy of your project using “svn copy”.

svn copy <https://mysvnrepo.com/svn/path/to/trunk> \ <https://mysvnrepo.com/svn/path/to/branch_name> \ -m "commit message"

Tags

There is no difference between branches and tags in Subversion. The only difference is in what the user then does with the directory. Branches are typically created, edited, and then merged back into the trunk. Alternatively, tags are created as a snapshot of the project at a point in time and then never changed.

Typically, tags are used to create a snapshot of your project at a certain stage. They are not used for development and working on a tag revision is not a good idea.

If you need to make changes to a release which has already been tagged, create a new branch from the tag and then commit the branch. Do all of your work on the branch, and then create a new tag from that branch.

Creating a tag is exactly the same as creating a branch. The only difference is that the tag will be located inside of the tags directory instead of the previous branches directory.

SVN Ignore

• http://blog.bogojoker.com/2008/07/command-line-svnignore-a-file/
• http://superchlorine.com/2013/08/getting-svn-to-ignore-files-and-directories/

You don’t svn:ignore a file.
You put an svn:ignore property on the directory to ignore that filename pattern!

# Go to the repo trunk directory:
cd trunk/

# Add just the single file to the current directories ignore list (like above)
# Note the dot at the end of the command is important
svn propset svn:ignore secret.txt .

Ignore an Existing File

If the file is already under version control or shows up as ‘M’ instead of ‘I’, then you’ll first have to svn delete the file from the repository (make a backup of it somewhere first), then svn ignore the file using the steps above and copy the file back into the repository.

List ignored files

svn propget svn:ignore .

Status including ignored files

svn status --no-ignore