Tidbits pulled from the svnbook.

Basic subversion:

user:$ svn clone {{ REPO_URL }}
user:$ svn info
user:$ svn update
user:$ svn add . --force
user:$ svn commit -m "{{ MESSAGE }}"

For git-svn, can try perusing this git-svn helpsheet:

user:$ git svn clone {{ REPO_URL }}
user:$ git status
user:$ git svn rebase
user:$ git add .
user:$ git commit -m "{{ MESSAGE }}"
user:$ git svn dcommit --rmdir

Boilerplate for subversion, as well as git-svn integration

user:$ make pull
user:$ git add .
user:$ git commit -m "{{ MESSAGE }}"
user:$ make push

user:$ cat Makefile
# Check if repository created with git-svn
IS_GIT:=$(shell [ -d .git/svn ] && [ x != x"$$(ls -A .git/svn/)" ] && echo 1 )
.PHONY: config clean reset build
 
ifneq (${IS_GIT},)
# Git-svn commands
# Note this fails if commits not merged; stash first
update up pull:
        @git stash
        @git svn rebase
        @-git stash pop
        @git status
commit co push:
        git svn dcommit --rmdir
clean-all: reset clean
clean:
        git clean -dfx
        git svn mkdirs
reset:
        git reset --hard
# svn:ignore seems to only be settable by svn directly
# Ignoring 'git svn create-ignore' for now
config:
        cp .svnignore .gitignore
 
else
# Subversion maintenance
# Hooks seem to enforced server-side, so we delete files manually instead
update up:
        @svn update
        @svn status | awk '/^[!]/{print $$2}' | xargs -I{} svn remove {}
        @svn status
clean:
        svn cleanup --remove-ignored .
clean-all:
        svn cleanup --remove-ignored --remove-unversioned .
# git-svn does not react well to comment lines in svn:ignore
config:
        cat .svnignore | grep -v "#" | xargs -I{} rm -f {}
        svn propset svn:ignore "$$(cat .svnignore | grep -ve '^#' -e '^$$')" .
 
endif
 
 
 
# For Subversion ignore files
$ cat .svnignore 
# Reminder, build directory in 'build'
#
# Delete files:  cat .svnignore | grep -v "#" | xargs -I{} rm -f {}
# Update ignore: svn propset svn:ignore -F .svn_ignore .
# View ignore:   svn propedit svn:ignore .
main.aux
main.bbl
main.blg
main.log
main.synctex.gz
mainNotes.bib
main.pdf
 
 
# For VSCode Latex Workshop
user:$ cat .vscode/settings.json 
{
  "latex-workshop.latex.outDir": "%DIR%/build"
}

Assuming one already knows git, i.e. a version control system that allows multiple people to pull local copies of a remote hosted repository and push changes upstream. Git is 'distributed', i.e. entire copies of the repository are copied locally. Subversion on the other hand is 'centralized', i.e. a single revision of each file is pulled into the local repository.

Every pull from the subversion repository retrieves the latest working copy (or a specified revision) of files in the repository. Subversion interestingly supports the concept of 'mixed revisions', where files can share different revisions. This features arises from the subversion repository only updating the revisions of locally changed files and leaves the rest untouched. Directories can only be updated when the revision diff is generated relative to the latest revision of that file on the server.

Each subversion repository is hosted on the server as a HTTP(S) endpoint, but also allows checking out of subtrees of the repository. Git requires checking out the entire repository.

On Ubuntu 20.04, run:

sudo apt install subversion

On Windows and others, consider using a subversion client such as Tortoise SVN.

Setting up a subversion server is a little more involved, and requires Apache as the client-facing webserver with the mod_dav_svn module, or alternatively using a svnserve daemon as a lightweight server. This page assumes someone already set up the subversion repository you'll be working with for you. Alternatively, you can setup a local subversion repository, using the file:// URI handler instead of svn:// or https://.

Clone branch, verify repo status and update, and view existing properties:

svn up
svn info
svn log
svn proplist -Rv

Decide which files should be versioned:

svn add {{ FILES }}
svn delete --keep-local {{ FILES }}
svn revert {{ FILES }}

Verify changes and commit, before pulling again:

svn diff
svn commit -m "{{ MESSAGE }}"
svn up
svn info

Properties are set on directories, help found in svn help propset:

shell$ svn propedit svn:ignore {{ DIRECTORY }}
shell$ cat .svn_ignore
# Reminder, build directory in 'build'
#
# Delete files:  cat .svn_global-ignores | grep -v "#" | xargs -I{} rm -f {}
# Update ignore: svn propset svn:ignore -F .svn_ignore .
# View ignore:   svn propedit svn:ignore .
main.aux
main.bbl
main.blg
main.log
main.synctex.gz
mainNotes.bib
main.pdf

If files have been locally deleted but not updated on the subversion, go with:

svn status | grep ^! | awk '{ print $2 }' | xargs svn remove

For a deeper clean, use:

svn cleanup --remove-ignored --remove-unversioned .

If attempting to avoid committing a particular file, consider using changelists (can also be supplied as argument multiple times):

svn changelist {{ CLIST_NAME }} {{ FILES }}
svn changelist {{ CLIST_NAME }} --remove {{ FILES }}
svn diff --changelist {{ CLIST_NAME }}
svn commit --changelist {{ CLIST_NAME }} -m "{{ MESSAGE }}"

This guide is adapted from the official Apache quick start guide. The first step is typically to checkout a working copy of the repository.

svn checkout --username <USERNAME> <HTTPS_ENDPOINT>

If setting up a new project in a separate branch of the repository, a directory can be imported as a subtree of the repository. Recall that multiple unrelated projects can co-exist on the same repository (although typically different development branches).

svn import <HTTPS_ENDPOINT> -m "Initial commit"

Latest updates to the repository (or subtree) can be regularly pulled.

svn update

Local changes to files can be made. Note that unlike git, subversion does not perform heuristic-based directory operations, e.g. move/copy are not tracked when performed outside of subversion commands. Common file/directory operations:

# See pending commit diff
# always do this prior to pushing commits
svn diff

# Track local changes / new files
# i.e. marks files for committing to repository
svn add <FILE>

# Delete files
svn delete <FILE>

# Reverse an unintended add
# e.g. added local files that should not be in the repository
# https://stackoverflow.com/questions/5083242/undo-svn-add-without-reverting-local-edits
svn delete --keep-local <FILE>

# Discard local changes (permanent!)
svn revert <FILE>

# Move/Rename and Copy files
svn move <SRC_FILE> <DEST_FILE>
svn copy <SRC_FILE> <DEST_FILE>

The mainline is typically denoted as the 'trunk', i.e. where main development is ongoing. Feature branches can be created by making a copy of the current state of the repository, i.e. using svn copy. This does not take up much extra space, probably handled as symbolic links to individual revisions by the subversion server.

svn copy <TRUNK_ENDPOINT> <BRANCH_ENDPOINT> -m "Creating a new branch"

Tags are read-only copies (branches) of the mainline, reserved for major releases.

A typical subversion repository is thus organized as such:

REPO_ROOT/REPO/trunk
REPO_ROOT/REPO/branches/*
REPO_ROOT/REPO/tags/*

Two options for extracting copies of the repository (without svn repo information):

• svn export [URL] if credentials are available, but no write-access given
• wget [URL] if no credentials available, but anonymous read-access given