:Temporary home for KDE applications that are believed to have reached release-quality. From here, once all major issues are resolved, applications are moved either to <tt>/trunk/KDE/</tt> or to <tt>/trunk/extragear/</tt>

:The Valgrind application, which is hosted on the KDE repository, but that is not part of KDE itself. Note that newer versions of Valgrind are developed on their own repository. The KDE Valgrind modules only holds up to Valgrind 2.4.

Aktualisieren

In order to update, you use the update subcommand.

This is no different from CVS: you change into your checked out copy (for those new to this whole process, the checked out copy should be in your Home folder) and issue a svn update (or, shorter, svn up) command.

Den Status einer Datei ermitteln

To know which local files you had modified, in CVS most people did

cvs up

and looked at the files with M, this does not work with svn so you have to do

svn status

to know the status of the files.

Ins Repository hochladen

Just like in CVS, committing to the Subversion repository is accomplished
with the commit or checkin (ci for short) subcommands.

CVS command:

cvs commit
# or
cvs ci
# or
cvs ci filename.cpp

Subversion command:

svn commit
# or
svn ci
# or
svn ci filename.cpp

This way, svn will launch the editor specified in $SVN_EDITOR for you
to compose the commit message. If you prefer, you can give svn the -m
oprtion with your full message:

svn ci -m "Updating protocol to conform to HTTP/1.1"

Dateien ignorieren

Subversion stores ignored files per directory. To edit the ignored
files of the directory you are currently in, do

svn propedit svn:ignore .

that will launch your editor, write there the names of the files you want to
ignore, one file per line. Once you are done, do a commit so the ignored list
file gets updated on the server.

A lot of files were ignored in CVS with help from global ignore list which
is not supported yet by SVN. You can wait for svn 1.3 or you need to add the
ignore list to the [miscellany] group in your ~/.subversion/config (all in
one line):

Working with multiple revisions and branches

Unlike CVS, Subversion doesn't generate a revision number for each file
modified. Instead, the full repository is versioned, as a whole. This way, a
given revision number represents the state the repository was on a given date.
In other words, a revision number is like a timestamp (in fact, the Subversion
server uses this fact to search for dates in the repository faster).

So, for instance, when you check out the KDE repository, Subversion will
tell you the following:

Updated to revision 403821.

This means that the latest revision available at the time of the operation
was 403821. If you make a modification and commit, Subversion will update the
server-side revision and will inform you of it. Like CVS, only the committed
files will be updated: you will need run cvs up to update the rest of the
files.

If you want to retrieve a specific revision of a file, you can use the -r
switch. Besides the revision number itself, -r accepts a number of other
possibilities:

The revision number: for example, use -r 403819 to retrieve that version

BASE: the revision you updated to

COMMITTED: the revision a file was last modified, before BASE

PREV: the revision of the previous commit to the file before COMMITTED

HEAD: the most recent revision available in the server

{ date }: between curly brackets, you can specify a date for searching the closest revisions

The following illustrates the evolution of the keywords:

You run svn up to update to the latest available revision. Suppose Subversion tells you it updated to revision 403821. This means that HEAD and BASE are 403821.

You modify file README and commit it. Suppose Subversion tells you it committed revision 403822. This means HEAD, BASE and COMMITTED are 403822.

You modify the file again and commit it. Now PREV is 403822, but HEAD, BASE and COMMITTED are updated to a new value (suppose it's 403823).

Now someone else modifies the repository, and you update your working copy. If Subversion tells you it updated to 403824, this means now HEAD and BASE are moved to 403824 (but PREV and COMMITTED stay the same)

If someone modifies the README file now, HEAD is moved. The other keywords stay the same for you, until you update. At this time, we will have HEAD = 403825 (the latest available revision), BASE = 403824 (the revision you last updated to), COMMITTED = 403823 (the revision of the latest change to the file when you last updated) and PREV = 403822 (the revision of the change before COMMITTED)

Those keywords are useful to retrieve logs and diffs for commits to the
repository.

If you want to see the difference between your working copy and BASE, you
can run:

svn diff

This is a very fast operation, since Subversion keeps a local copy of BASE.
It doesn't need a network connection to accomplish this operation.

If you want to see the difference between your local copy and the latest
available on the server, you will run:

svn diff -r HEAD

If you want to see what has changed in the repository since you've last updated, you can use:

svn diff -r BASE:HEAD

If you want to see the last change to a file before BASE, you can use:

svn diff -r PREV:BASE
# or
svn diff -r PREV:COMMITTED

That is also valid for the svn log command.

Unterverzeichnisse von anderen Orten verlinken

It can happen you would like to include a copy of a subdirectory from another place, but just for convenience, not for developing the code in there. Of course it should be updated automatically whenever the original changes. Subversion can help you. You need to edit the property svn:external of the directory the subdirectory should be added to. So for the current directory you use

Updating will now fetch /trunk/playground/pim/khalkhi into the subdirectoy libkhalkhi.

{{{3}}}

Beware that you cannot commit changes you did to the local copy of the external subdirectory, it is just a readonly copy.

Warnung

You use svn://anonsvn.kde.org and not another protocol, because anonsvn.kde.org is accessible to everyone. Using https: or svn+ssh: would only work for users of that protocol. There are still some small disadvantage with anonsvn.kde.org: It is not always in synchronization with svn.kde.org, so updates in the original branch may take a while to appear on anonsvn.kde.org. And some strict firewalls are blocking the svn: protocol.

A special case in KDE 3 is the subdirectory admin, containing the KDE 3 build utilities. It is linked in to the top directory in all modules, and maintained in /branches/KDE/3.5/kde-common. For admin the KDE subversion server is configured to allow readonly access for everyone, so if you see