Publication Date 18 Jan 2012
| Authors |
$Id: svndoc.xml 472 2011-12-29 08:56:00Z taroth21 $
Contents
Subversion is, like CVS, a tool for managing source files. It keeps track of your work and changes in a set of files and directories. It allows developers and writers to collaborate. The common area is the repository, where all files are stored. The repository can reside on a local directory, but it is usually accessible over a network.
Working with Subversion involves the following steps:
You check out your working directory from the repository. This needs to be done only once.
You modify your files, for example, insert new sections or delete some paragraphs.
You can check the status of your working directory.
If you have write permission, you check in your changes to the repository. With read access only, you must find someone with write permission if you want to keep these changes.
At the same time, other users with write access to the repository might check in their modifications. To get these changes, update your working directory.
If you change a file and another person changed it too, you might get conflicts with the next update. This rare case occurs if two people edit the same lines of the same file. Subversion cannot decide which version is better, so you must resolve the conflict manually.
For more information, see [svn]. Although you can work with Subversion on Windows, this guide is targeted to Linux.
For your daily work, use the svn command. It knows
--help. You can even get the options for a certain
Subversion command, for example svn update
--help. This prints the available options
for the update procedure of Subversion.
A typical work cycle looks like this (taken from the Subversion Book):
Procedure 1. A typical Work Cycle during Development
Update your working copy
svn update, see Section 6, “Updating your Working Directory”
Make changes
svn add, see Section 10, “Adding and Removing Files”
svn delete, see Section 10, “Adding and Removing Files”
svn copy, see Section 11, “Copying and Renaming Files”
svn move, see Section 11, “Copying and Renaming Files”
Examine your changes
svn status, see Section 7, “Examine your Changes”
svn diff, see Section 8, “Diffing your Changes”
svn revert, see Section 12, “Reverting Changes”
Merge others' changes
svn merge
svn resolved, see Section 13, “Resolving Conflicts”
Commit your changes
svn commit, see Section 14, “Checking in your Modifications”
Tag your work after finishing
svn copy, see
Section 9, “Tagging your current trunk”
Before you start, you should know about Subversion:
Subversion is platform neutral; it runs on Linux, MacOS, Windows and some others
You can run Subversion with the help of a GUI (graphical user interface) or by typing the respective commands in a shell
There are some packages that are essential or might be useful if you work with Subversion:
Table 1. Essential and useful packages¶
| Package | Description |
|---|---|
subversion | This is essential. You can not work without this package |
subversion-doc | The documentation of Subversion. If you need in-depth information, this is the right place to look. |
kdesvn | GUI for Subversion. This let you access the repository through a GUI. |
The configure check needs additional packages:
make
automake
autoconf
Before you work with Subversion, you should check whether all relevant packages are installed. Proceed as follows:
Procedure 2. Setting up your Subversion Working Environment¶
Find a place where you have lots of free space and write access. It is important that you do not run out of space. Between 2 and 3 GB should be enough, but more is always better.
Configure Subversion
Check, if you have a directory .subversion in your home directory. If
not, create it:
mkdir ~/.subversion
Insert the following line into your ~/.bashrc or
~/.bashrc.local:
export SVNROOT="https://forgesvn1.novell.com/svn/novdoc"
This simplifies the typing of your commands.
The first step when working with Subversion is to check out your files from a repository. This step must be done only once, but it is essential.
Procedure 3. Checking out
Open a shell
Check out an init script that does most of the tedious work (one line):
svn cat $SVNROOT/trunk/bin/initdoc.py > initdoc.py
You have to enter the password anonymous twice.
Set the excecution permission:
chmod +x initdoc.py
Run the command. Use as first parameter the directory where you want to store the hole stylesheets and book source codes:
./initdoc.py WORKING_DIRECTORY
This script creates a directory SUSEDOC/ inside
WORKING_DIRECTORY.
![]() | Change the language |
|---|---|
Your language is determined by the | |
Change to your directory:
cd WORKING_DIRECTORYFrom time to time, you should update your working directory to get changes others have made:
Open a shell and go to the directory where the book file
resides, for example, books:
cd WORKING_DIRECTORY/doc/trunk/books/Run the update process:
svn update
The svn update might give an
output, see Section 7, “Examine your Changes” for more information.
The next action depends on the status of the file. If you have modified a file, you probably want to check in your changes. If your file is added or removed, a commit would solve this problem. For files with a conflict, resolve the conflict before handing it to Subversion.
Before you checking in your changes, it is always a good idea to take
a look at exactly what you have changed. Subversion prints the status of
your working directory with svn status. The output of this commands contains six columns:
This is the most important column
| (space) no modifications | |
A | Added |
C | Conflicted |
D | Deleted |
G | Merged |
I | Ignored |
M | Modified |
R | Replaced |
X | item is unversioned, but is used by an external definition |
? | item is not under version control |
! | item is missing (removed by non-svn command) or incomplete |
~ | versioned item obstructed by some item of a different kind |
This is probably the second most important column.
| (space) no modifications | |
C | Conflicted |
M | Modified |
| (space) not locked | |
L | Locked |
| (space) no history scheduled with commit | |
+ | history scheduled with commit |
Only used for switching and is not relevant for us at the moment. See svn status --help for more information.
Not relevant for us at the moment. See svn status --help for more information.
If you do not know, which changes did you make, try svn
diff. You can diff your files even if you
are not online—Subversion holds a copy of the last revision.
To get the differences between your current, modified file and the last revision, run:
svn diff foo
To get the difference between your working copy and the trunk revision, run:
svn diff
However, you can also diff between revisions that are already checked in. Subversion knows the following revision keywords:
Revision Keywords (taken from the Subversion Book)
The latest revision in the repository.
The revision you last updated to
The revision of the latest change to the file when you last updated. Or in other words: The last revision in which an item changed before (or at) BASE.
The revision just before the last revision in which an item changed. (Technically, COMMITTED − 1.)
Here are some examples (taken from the Subversion Book):
svn diff --revision PREV:COMMITED foo # shows the last change committed to foo svn log --revision HEAD # shows log message for the latest repository commit svn diff --revision BASE:HEAD # shows all commit logs since you last updated
This section is probably useful to SUSE employees only. However it can be informative for other as well.
Tags are “snapshots of a project in time”. To create a tag for our books, enter:
svn copy $SVNROOT/trunk/books/en \
$SVNROOT/tags/books/en/TAG_NAMEReplace TAG_NAME with an appropriate name.
If you need to add new files or remove old files, use
the commands svn add and
svn remove.
To add a new file, enter:
svn add NEW_FILETo delete an old file, enter:
svn remove OLD_FILEIf you are finished with adding or deleting files, commit your changes:
svn commit
Unless CVS, Subversion can copy a file and retain its history. Subversion copies a file from a source to a destination. There are four possibilities where the source and destination are located:
From a working copy to a working copy (WC -> WC)
From a working copy to an URL (WC -> URL)
From an URL to a working copy (URL -> WC)
From an URL to an URL (URL -> URL). Used to branch & tag
In general, you can copy a file A to a file
B with the following command:
svn copy A B
After a svn status you can see
the new file B is scheduled for addition. It looks
like if you have added and removed a file.
To rename or move a file from a source to a destination, use
svn move or svn
rename (the two commands are the same, they
are just synonyms.) For example:
svn rename X Y
This renames X to Y. After
a svn status you can see the renamed file
is scheduled for addition.
After you copied or renamend the files, you must check in if you want to save it in the repository:
svn ci -m"Copied file" A B svn ci -m"Renamend file" X Y
If you want to discard your local changes, you can use the
svn revert command. It reverts any
local changes to a file, directory or any property changes. It can revert
scheduling operations like addition, renaming or deletion only. For example:
svn add foo svn revert foo svn rename foo bar svn revert foo bar svn delete foo svn revert foo
![]() | No targets to svn revert is a protection |
|---|---|
The Subversion book [svn] says: “If you
provide no target to svn | |
Conflicts occur only when all of the following conditions are met:
Two users edit the same file.
These two users also edit the same line.
One of them commits the changes and the other updates.
If you update your working directory and Subversion detects a conflict, it changes the contents of the file and inserts “conflict marks”:
<<<<<<< .mine This is a nice line. ======= This is a short line. >>>>>>> .r4
You have the following possibilities:
Remove your version and update the file. You get the latest version from Subversion. This solution works if you do not want to keep your changes. Or
Resolve the conflict.
To resolve the conflict, proceed as follows:
Open the file containing the conflict.
Search for conflict marks. These marks have the general format:
<<<<<<<FILENAMELines that you have changed ======= Lines from the repository >>>>>>>.last revision number from repository
Decide which version is preferred (yours or the repository's), or merge the two lines, delete the conflict marks, and save the result.
Remove the conflict state with:
svn resolved FILENAMEThe command svn resolved fixes some bookkeeping data.
Check in your changes
svn ci FILENAMEAfter you have changed, added, or removed files in your local working directory, you have to commit your files back to the Subversion repository:
Change your directory to the book sources.
Run:
svn ci NAME_OF_YOUR_FILE(S)Replace NAME_OF_YOUR_FILE(S) with the
name of your changed file(s). The editor vi opens.
![]() | Check the files before commit |
|---|---|
It is possible to check in with the command svn ci. However, practice showed, that you get modified files that you do not want to check in at this stage. For this reason it is probably a good idea to always insert the files in the command line. | |
Press i to insert your login message.
Close the editor with : w q. Subversion commits your file(s) with your commit message.
If you want to cancel the commit, press : q ! in the vi editor. Subversion lets you determine your actions. Abort with a.
![]() | Checking in is always a good Idea |
|---|---|
Do not hesitate to check in your changes. If you have checked your changes back in our Subversion repository, you are protected from hard disk crash or other loss of data. In other words: Subversion is your backup system. Please make sure that you always check in valid XML. | |
If you want to see the history of your files use the svn
log command. For example:
svn log xml/help.xml ------------------------------------------------------------------------ r2913 | tom | 2005-12-19 13:34:17 +0100 (Mo, 19 Dez 2005) | 1 line docmanager: Property »doc:status« set to »proofed« ------------------------------------------------------------------------ r2912 | tom | 2005-12-19 13:33:19 +0100 (Mo, 19 Dez 2005) | 2 lines worked on comments ------------------------------------------------------------------------ r2877 | rwalter | 2005-12-18 18:52:07 +0100 (So, 18 Dez 2005) | 1 line docmanager: Property »doc:status« set to »comments« ------------------------------------------------------------------------ r2876 | rwalter | 2005-12-18 18:49:53 +0100 (So, 18 Dez 2005) | 3 lines proofing and comments ...
It is more convenient to pipe it to less to browse a long history:
svn log xml/help.xml | less
Quit with q.
Sometimes you need to restore an old revision from the Subversion repository. Do the following:
Check if your respective file is unchanged. If there are changes
that you do not want to loose, check in first otherwise run
svn revert FILENAME
Determine your revision with svn
log. See also Section 15, “Viewing History”.
Restore your revision and save it; for example (replace
REVISION from the last step):
svn cat -rREVISION \
$SVNROOT/trunk/books/en/xml/foo.xml > xml/foo.xmlCheck in your changes with a meaningful log message.