Getting Started/Sources/Subversion: Difference between revisions

    From KDE TechBase
    (initial port of: http://developer.kde.org/documentation/tutorials/subversion/)
     
    No edit summary
    (49 intermediate revisions by 16 users not shown)
    Line 1: Line 1:
    This is a quick KDE-specific introduction, for all Subversion details read the
    {{warning|This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the [[Development/Git|KDE Git hub page]] for more details. }}
    "[http://svnbook.red-bean.com/ Version Control with Subversion]" book.


    == Getting started ==


    In order to use the KDE Subversion repository, you will need two things:
    {{TutorialBrowser|


    # A Subversion client program
    series=Getting Started|
    # An account in our repository


    Note: For anonymous read-only access use protocol "svn", no "yourname@" and server "anonsvn.kde.org" instead below.
    name=Using Subversion With KDE|


    '''Installing Subversion:''' instructions on installing the client are not
    reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
    presented here. Refer to your system installation instructions to find out how
    you can install Subversion. You will need version 1.1 at least. If you are
    compiling from sources and want to access the KDE repository by https
    (and not by svn+ssh), you will need SSL and ZLIB supports,
    so you will need the <code>--with-ssl --with-zlib</code> options.


    Alternatively, you can install one of the many graphical clients out there.
    reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
    This tutorial is intended for people using the <tt>svn</tt> program only, referring
    }}
    to tasks accomplished with the usual <tt>cvs</tt> program.


    '''Getting an account:''' if you had a CVS
    == Abstract  ==
    account before, it has been migrated to the new Subversion client. If
    you didn't, refer to the [[Contribute/Get_a_SVN_Account|corresponding tutorial]] how to get one.


    Note: if you have lost your CVS password, there are simple ways to retrieve
    This is a quick KDE-specific introduction for using subversion to access files and software in KDE's repositories. For comprehensive coverage of Subversion we recommend reading the book "[http://svnbook.red-bean.com/ Version Control with Subversion]".  
    it. Use [http://ktown.kde.org/~coolo/cvspwd.c cvspwd.c] or
    [http://kdab.net/~dfaure/cvs-unscramble cvs-unscramble] (Perl).


    [#top Top]
    == Getting started  ==


    == The KDE repository structure ==
    In order to use the KDE Subversion repository, you will need a&nbsp;Subversion client program.
     
    If you only need SVN for checking out the sources (read-only), use the protocol: "svn" at the server:&nbsp;"anonsvn.kde.org".
     
    So for example, instead of what you see throughout this tutorial, your paths would show a similarity to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop
     
    Note: Wherever it mentions "yourname@", http, https, or passwords, you should ignore those and use what is mentioned. None of that stuff is needed for the anonymous server.
     
    If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here:&nbsp;[http://techbase.kde.org/Contribute/Get_a_SVN_Account get an SVN Account].<br>
     
    ----
     
    '''Installing Subversion:''' instructions on installing the client are not presented here. Refer to your system installation instructions to find out how you can install Subversion. You will need version 1.1 at least. If you are compiling from sources and want to access the KDE repository by https (and not by svn+ssh), you will need SSL and ZLIB support, so you will need the <tt>--with-ssl --with-zlib</tt> options.
     
    Alternatively, you can install one of the many graphical clients out there(for example, kdesvn, albeit unofficial). This tutorial is intended for people using the <tt>svn</tt> program only, referring to tasks accomplished with the usual <tt>cvs</tt> program.
     
    '''Getting an account:''' if you have had a CVS account before, it has been migrated to the new Subversion client.
     
    == The KDE repository structure ==


      svn.kde.org/home/kde
      svn.kde.org/home/kde


    That's the address of the KDE Subversion repository. The repository is served by
    That's the address of the KDE Subversion repository. The repository is served by HTTPS or SVN+SSH protocol, which means your password is secure against third-party eavesdropping.  
    HTTPS or SVN+SSH protocol, which means your password is secure against third-party
     
    eavesdropping.
    The SSL certificate md5 fingerprint for the repositories:


    The SSL certificate md5 fingerprint for the repositories:
      F6BF EDE2 D016 D1B2  4F18 742E 2C8F B7EF
      F6BF EDE2 D016 D1B2  4F18 742E 2C8F B7EF


    The SSL certificate sha1 fingerprint for the repositories:
    The SSL certificate sha1 fingerprint for the repositories:  
     
      e1:e6:41:96:3c:eb:ae:78:e2:73:0d:a2:32:2f:6b:21:13:bf:3d:0f
      e1:e6:41:96:3c:eb:ae:78:e2:73:0d:a2:32:2f:6b:21:13:bf:3d:0f


    For people using svn+ssh, here's the fingerprint of the server's RSA key:
    For people using svn+ssh, here's the fingerprint of the server's RSA key:  
    86:f3:66:06:20:74:81:d0:1b:b4:2f:25:03:f7:8e:fb


    The repository is organised in main directories:
    1e:89:fa:0d:c3:11:a4:81:36:84:b6:f2:6b:f0:5b:ad


    # /branches
    The repository is organised in main directories:
    # /tags
    # /trunk


    You can explore the repository structure at [http://websvn.kde.org/ http://websvn.kde.org/]
    #/branches
    #/tags
    #/trunk


    You can explore the repository structure at [http://websvn.kde.org/ http://websvn.kde.org/]


    === The top-level directory /trunk ===
    <br>


    The <tt>/trunk</tt>
    === The top-level directory /trunk  ===
    top-level subdirectory is where the main development for KDE occurs.
    What you will find here is what will become the next KDE release, and
    of its associated programs. You will also find here the <tt>www</tt> module,
    which contains webpages for KDE's site and related ones.


    <tt>/trunk</tt> is further subdivided into these sub-directories:
    The <tt>/trunk</tt> top-level subdirectory is where the main development for KDE occurs. What you will find here is what will become the next KDE release and its associated programs. Here you will also find the <tt>www</tt> module, which contains webpages for KDE's site and related ones.
     
    <tt>/trunk</tt> is further subdivided into these sub-directories:  
     
    *<tt>KDE/</tt><br>KDE itself, what will become the next public release. It contains the following modules:
    **'''kdelibs''' - KDE basic libraries, used by all KDE programs
    **'''kdebase''' - KDE base programs, like the KDE Control Center, Kicker (the panel) and Konqueror (the web browser)
    **'''kdeaccessibility''' - Accessibility files
    **'''kdeadmin''' - KDE Administration applications
    **'''kdeartwork''' - Images, themes, sounds and other art files
    **'''kdebindings''' - Bindings for languages other than C++
    **'''kdeedu''' - KDE Educational applications
    **'''kdegames''' - KDE Games
    **'''kdegraphics''' - KDE Graphical applications
    **'''kdemultimedia''' - KDE Multimedia applications
    **'''kdenetwork''' - KDE Networking applications
    **'''kdepim''' - KDE Personal Information Management applications
    **'''kdepimlibs''' - Libraries used by KDE-PIM applications.
    **'''kdesdk''' - KDE Software Development Kit applications
    **'''kdetoys''' - KDE toy applications
    **'''kdeutils''' - KDE General utilities
    **'''kdewebdev''' - KDE Web development applications
    *<tt>kde-common</tt>
     
    :Common admin/ directory


    *<tt>KDE/</tt>
    :KDE itself, what will become the next public release. It contains the following modules:
    **'''arts''' - Soundserver (removed in KDE 4)
    **'''kde-common''' - Common admin/ directory
    **'''kde-i18n''' - Translations
    **'''kdelibs''' - KDE basic libraries, used by all KDE programs
    **'''kdebase''' - KDE base programs, like the KDE Control Center, Kicker (the panel) and Konqueror (the web browser)
    **'''kdeaccessibility''' - Accessibility files
    **'''kdeaddons''' - Add-ons and plug-ins to KDE programs
    **'''kdeadmin''' - KDE Administration applications
    **'''kdeartwork''' - Images, themes, sounds and other art files
    **'''kdebindings''' - Bindings for languages other than C++
    **'''kdeedu''' - KDE Educational applications
    **'''kdegames''' - KDE Games
    **'''kdegraphics''' - KDE Graphical applications
    **'''kdemultimedia''' - KDE Multimedia applications
    **'''kdenetwork''' - KDE Networking applications
    **'''kdepim''' - KDE Personal Information Management applications
    **'''kdesdk''' - KDE Software Development Kit applications
    **'''kdetoys''' - KDE toy applications
    **'''kdevelop''' - The KDevelop program
    **'''kdeutils''' - KDE General utilities
    **'''kdewebdev''' - KDE Web development applications
    *<tt>bugs/</tt>
    *<tt>bugs/</tt>
    :[http://bugs.kde.org/ Bugzilla] files
    :[http://bugs.kde.org/ Bugzilla] files
    *<tt>developer.kde.org/</tt>
    *<tt>developer.kde.org/</tt>
    :The content of developer.kde.org
    :The content of developer.kde.org
    *<tt>extragear/</tt>
    *<tt>extragear/</tt>
    :KDE programs outside the main KDE releases.
    :KDE programs outside the main KDE releases.
    *<tt>kdereview/</tt>
    *<tt>kdereview/</tt>
    :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>
    :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>
    *<tt>kdesupport/</tt>
    *<tt>kdesupport/</tt>
    :Supporting applications and libraries for KDE
    :Supporting applications and libraries for KDE
    *<tt>koffice/</tt>
     
    :The KDE Office suite, containing the programs:
    *<tt>koffice/</tt><br>The KDE Office suite, containing the programs:  
    **'''karbon'''
    **'''karbon'''  
    **'''kchart'''
    **'''kchart'''  
    **'''kdatabase'''
    **'''kexi'''  
    **'''kexi'''
    **'''kformula'''  
    **'''kformula'''
    **'''kivio'''  
    **'''kivio'''
    **'''koshell'''  
    **'''kontour'''
    **'''kplato'''  
    **'''kplato'''
    **'''kpresenter'''  
    **'''kpresenter'''
    **'''krita'''  
    **'''krita'''
    **'''kspread'''  
    **'''kspread'''
    **'''kword'''  
    **'''kugar'''
    **'''kword'''
    *<tt>konstruct/</tt>
    *<tt>konstruct/</tt>
    :Konstruct, the KDE build program
    :Konstruct, the KDE build program
    *<tt>l10n-kde3/</tt>
    :Translations for the "unstable" modules of KDE 3 (extragear, playground)
    *<tt>l10n-kde4/</tt>
    :Translations for KDE 4
    *<tt>playground/</tt>
    *<tt>playground/</tt>
    :The KDE playground: applications being developed, but not having yet reached release-quality.
    :The KDE playground: applications being developed, but not having yet reached release-quality.
    *<tt>qt-copy/</tt>
    *<tt>qt-copy/</tt>
    :The convenience copy of [http://www.trolltech.com/ Trolltech's] Qt library, which KDE is based upon.
     
    :The convenience copy of [http://www.trolltech.com/ Trolltech's] Qt library, which KDE is based upon. Remember, this is deprecated, you should be using the git repository, kde-qt instead. Qt-copy is at version 4.5, yet trunk '''requires '''
     
    *<tt>tests/</tt>
    *<tt>tests/</tt>
    :khtml, KOffice and ksvg testcases
    :khtml, KOffice and ksvg testcases
    *<tt>valgrind/</tt></dt>
     
    :The Valgrind application, which is hosted on the KDE repository, but that is not part of KDE itself.
    *<tt>valgrind/</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.
     
    *<tt>www/</tt>
    *<tt>www/</tt>
    :Webpages for the KDE site (and related sites). Write access to this directory is restricted.
    :Webpages for the KDE site (and related sites). Write access to this directory is restricted.


    === The top-level directory <tt>/tags</tt> ===
    === The top-level directory <tt>/tags</tt> ===
     
    This directory contains the official releases of the programs maintained and developed in the KDE repository. Each individual application has a subdirectory here. Inside it, you will find the release numbers.
     
    For instance, the KDE 3.4.0 code can be found under <tt>/tags/KDE/3.4.0/</tt>.
     
    === The top-level directory <tt>/branches</tt>  ===


    This
    This directory contains the branch versions of the applications after a major release.  
    directory contains the official releases of the programs maintained and
    developed in the KDE repository. Each individual application has a
    subdirectory here. Inside it, you will find the release numbers.


    For instance, the KDE 3.4.0 code can be found under <tt>/tags/KDE/3.4.0/</tt>.
    Most KDE applications adhere to the philosphy that new features (as well as new user-visible strings) are added only to the next release cycle — the one that lives in <tt>/trunk/</tt>. However, bugfixes are applied to all applications, even after release.  


    === The top-level directory <tt>/branches</tt> ===
    In order to do that, a branch is created at the moment of the release, indicating the state of the files at that time. Bugfixes are then checked in to those files. Those branches are the ones in <tt>/branches/</tt>.


    This directory contains the branch versions of the applications after a major release.
    For instance, the KDE 3.4.x branch can be found under <tt>/branches/KDE/3.4/</tt>


    Most
    The subdirectories you will find inside <tt>/branches</tt> are the application subdirs, like <tt>akregator/</tt>, <tt>amarok/</tt>, <tt>arts/</tt>, <tt>k3b/</tt>, etc. You will also find a <tt>KDE/</tt> subdir, containing the official KDE releases since time immemorial.  
    KDE applications adhere to the philosphy that new features (as well as
    new user-visible strings) are added only to the next release cycle &#8212;
    the one that lives in <tt>/trunk/</tt>. However, bugfixes are applied to all
    applications, even after release.


    In
    One special subdir is found in <tt>/branches</tt>: <tt>work/</tt>. This subdir contains the so-called "work branches", that is, branches containing features being worked on, sometimes highly experimental. Multi-application work branches always are checked in to <tt>/branches/work/</tt>, but single-application branches may be found in each application's subdir. That is a decision left to the developers.  
    order to do that, a branch is created at the moment of the release,
    indicating the state of the files at that time. Bugfixes are then
    checked in to those files. Those branches are the ones in <tt>/branches/</tt>.


    For instance, the KDE 3.4.x branch can be found under <tt>/branches/KDE/3.4/</tt>
    <br>  


    The subdirectories you will find inside <tt>/branches</tt> are the
    == Checking out and updating  ==
    application subdirs, like <tt>akregator/</tt>, <tt>amarok/</tt>,
    <tt>arts/</tt>, <tt>k3b/</tt>, etc. You will also find a <tt>KDE/</tt>
    subdir, containing the official KDE releases since time immemorial.


    One special subdir is found in <tt>/branches</tt>: <tt>work/</tt>. This
    === Checking out  ===
    subdir contains the so-called "work branches", that is, branches containing
    features being worked on, sometimes highly experimental. Multi-application
    work branches always are checked in to <tt>/branches/work/</tt>, but
    single-application branches may be found in each application's subdir. That
    is a decision left to the developers.


    == Logging in to the KDE repository ==
    In order to check out something with Subversion, you use the <tt>checkout</tt> subcommand.


    The <tt>cvs login</tt> operation you used to perform is no longer necessary.
    '''WARNING:''' If you checkout trunk/KDE/ or branches/KDE/foo/ you will download complete kde-i18n!
    This operation is now performed during the checkout itself, since you
    access the Subversion Repository using its URL.


    == Checking out and updating ==
    Suppose you wanted to check out only kdeedu from the KDE repository. You would do:


    === Checking out ===
    Subversion users currently using ssh access should use protocol svn+ssh while subversion users currently using password access should use protocol https in the following:
    In order to check out something with Subversion, you use the <tt>checkout</tt> subcommand.


    '''WARNING:''' If you checkout trunk/KDE/ or branches/KDE/foo/ you will download complete kde-i18n!
    svn checkout --username=&lt;username&gt; &lt;protocol&gt;://svn.kde.org/home/kde/trunk/KDE/kdeedu


    Suppose you wanted to check out only KDevelop from the KDE repository. You would do:
    For checking out kdevelop from extragear you would do:


    CVS command:
      svn checkout --username=&lt;username&gt; &lt;protocol&gt;://svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop
      cvs -d :pserver:yourname@cvs.kde.org:/home/kde login
    cvs -d :pserver:[email protected]:/home/kde checkout kdevelop


    Subversion command:
    Note that you may wish to use the following if the above doesn't work:


    CVS users currently using ssh access, should use protocol svn+ssh,
    svn checkout &lt;protocol&gt;://&lt;username&gt;@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop
    CVS users currently using password access, should use protocol https
    in the following.


      svn checkout &lt;protocol&gt;://&lt;username&gt;@svn.kde.org/home/kde/trunk/KDE/kdevelop
    === Updating ===


    === Updating ===
    In order to update, you use the <tt>update</tt> subcommand.


    In order to update, you use the <tt>update</tt> subcommand.
    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 <tt>svn update</tt> (or, shorter, <tt>svn up</tt>) command.


    This is no different from CVS: you change into your checked out copy and issue a <tt>svn update</tt> (or, shorter, <tt>svn up</tt>) command.
    == Knowing the status of a file  ==


    == Knowing the status of a file ==
    To know which local files you had modified, you have to do


    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
      svn status
    to know the status of the files.


    == Committing to the repository ==
    and look at the files with '''M''' (for modified).


    Just like in CVS, committing to the Subversion repository is accomplished
    == Committing to the repository ==
    with the <tt>commit</tt> or <tt>checkin</tt> (<tt>ci</tt> for short) subcommands.


    CVS command:
    Committing to the Subversion repository is accomplished with the <tt>commit</tt> (<tt>ci</tt> for short) subcommands:
    cvs commit
    or
    cvs ci
    or
    cvs ci filename.cpp


    Subversion command:
      svn commit
      svn commit
    or
    # or
      svn ci
      svn ci
    or
    # or
      svn ci filename.cpp
      svn ci filename.cpp


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


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


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


    Subversion stores ignored files per directory. To edit the ignored
    files of the directory you are currently in, do
       svn propedit svn:ignore .
       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
    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.
    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 {{path|~/.subversion/config}} (all in
    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 {{path|~/.subversion/config}} (all in one line):  
    one line):


      global-ignores = *.o *.lo *.la .*.rej *.rej .*~ *~ .#* #*# .DS_Store *.moc
      global-ignores = *.o *.lo *.la .*.rej *.rej .*~ *~ .#* #*# .DS_Store *.moc
    Line 255: Line 247:
      Makefile.rules Makefile.calls autom4te.cache *.kidl
      Makefile.rules Makefile.calls autom4te.cache *.kidl


    == Working with multiple revisions and branches ==
    == Working with multiple revisions and branches ==


    Unlike CVS, Subversion doesn't generate a revision number for each file
    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).  
    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
    So, for instance, when you check out the KDE repository, Subversion will tell you the following:  
    tell you the following:


      Updated to revision 403821.
      Updated to revision 403821.


    This means that the latest revision available at the time of the operation
    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 <tt>cvs up</tt> to update the rest of the files.  
    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 <tt>cvs up</tt> to update the rest of the
    files.


    If you want to retrieve a specific revision of a file, you can use the <code>-r</code>
    If you want to retrieve a specific revision of a file, you can use the <tt>-r</tt> switch. Besides the revision number itself, -r accepts a number of other possibilities:  
    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:
    *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


    # You run <tt>svn up</tt> to update to the latest available revision. Suppose Subversion tells you it updated to revision 403821. This means that HEAD and BASE are 403821.
    The following illustrates the evolution of the keywords:
    # 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
    #You run <tt>svn up</tt> to update to the latest available revision. Suppose Subversion tells you it updated to revision 403821. This means that HEAD and BASE are 403821.
    repository.
    #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)


    If you want to see the difference between your working copy and BASE, you
    Those keywords are useful to retrieve logs and diffs for commits to the repository.
    can run:
     
    If you want to see the difference between your working copy and BASE, you can run:  


      svn diff
      svn diff


    This is a very fast operation, since Subversion keeps a local copy of BASE.
    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.  
    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
    If you want to see the difference between your local copy and the latest available on the server, you will run:  
    available on the server, you will run:


      svn diff -r HEAD
      svn diff -r HEAD


    If you want to see what has changed in the repository since you've last updated, you can use:
    If you want to see what has changed in the repository since you've last updated, you can use:  
     
      svn diff -r BASE:HEAD
      svn diff -r BASE:HEAD


    If you want to see the last change to a file before BASE, you can use:
    If you want to see the last change to a file before BASE, you can use:  
     
      svn diff -r PREV:BASE
      svn diff -r PREV:BASE
    or
    # or
      svn diff -r PREV:COMMITTED
      svn diff -r PREV:COMMITTED


    That is also valid for the <tt>svn log</tt> command.
    That is also valid for the <tt>svn log</tt> command.
     
    == Linking in subdirectories from other places  ==
     
    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 <tt>svn:external</tt> of the directory the subdirectory should be added to. So for the current directory you use
     
    svn propedit svn:externals .
     
    and then enter lines of the form
     
    libkhalkhi svn://anonsvn.kde.org/home/kde/trunk/playground/pim/khalkhi
     
    Updating will now fetch <tt>/trunk/playground/pim/khalkhi</tt> into the subdirectoy <tt>libkhalkhi</tt>.
     
    {{warning|Beware that you cannot commit changes you did to the local copy of the external subdirectory, it is just a readonly copy.}}
     
    You use <tt>svn://anonsvn.kde.org</tt> and not another protocol, because <tt>anonsvn.kde.org</tt> is accessible to everyone. Using <tt>https:</tt> or <tt>svn+ssh:</tt> would only work for users of that protocol. There are still some small disadvantage with <tt>anonsvn.kde.org</tt>: It is not always in synchronization with <tt>svn.kde.org</tt>, so updates in the original branch may take a while to appear on <tt>anonsvn.kde.org</tt>. And some strict firewalls are blocking the <tt>svn:</tt> protocol.
     
    A special case in KDE 3 is the subdirectory <tt>admin</tt>, containing the KDE 3 build utilities. It is linked in to the top directory in all modules, and maintained in <tt>/branches/KDE/3.5/kde-common</tt>. For <tt>admin</tt> the KDE subversion server is configured to allow readonly access for everyone, so if you see
     
    admin https://svn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
     
    there is no need to change this.
     
    == Further Links  ==
     
    *[[Development/Tools/svnmerge.py|Merge tracking with svnmerge.py]]
     
    = Old Getting_started/Sources/Anonymous SVN Page =
     
    == Abstract ==
     
    For those of us that like to stay on the "bleeding edge" there's an easy way to keep a local copy of the KDE sources up-to-date — anonymous SVN.
     
    Alternatively, install [[Getting_Started/Distribution_Packages|KDE SVN packages from your distribution]].
     
    == Anonymous SVN ==
     
    === Setup Subversion ===
     
    First, install the subversion (svn) binary if it isn't already on your computer. Your operating system should have a package for it. Alternatively you can download and compile it yourself via the [http://subversion.tigris.org/project_packages.html svn project download page]. Please read the [[Getting_Started/Sources/Using_Subversion_with_KDE|KDE Subversion tutorial]] if you are interested in how to use Subversion.
     
    === Checkout KDE TRUNK ===
     
    '''/trunk/''' is where the Qt4-based KDE 4 is being developed. The following is the minimal set of modules you will need to check out to build KDE and KDE software:
         
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepimlibs
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
     
    You also need to checkout KDESupport:
     
    svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport
     
    {{tip|If your firewall doesn't allow access to arbitrary ports, substitute '''svn://anonsvn.kde.org/''' with '''svn://anonsvn4.kde.org:443/''' above.}}
     
    {{tip|The kdebase module has an external dependency, using svn:externals. The problem is, at this time, the externals property is set with an absolute path, pointing to anonsvn. For those using behind a firewall, this is a problem. You can change the property for your workspace, using two commands:
    [[Getting_Started/Increased_Productivity_in_KDE4_with_Scripts/.bashrc|cs]] KDE
    svn propset svn:externals "lib svn://websvn.kde.org:443/home/kde/trunk/KDE/kdebase/runtime/kstyles/oxygen/lib" kdebase/workspace/kwin/clients/oxygen
    svn propset svn:externals "lib svn://websvn.kde.org:443/home/kde/trunk/KDE/kdebase/runtime/kstyles/oxygen/lib" kdebase/workspace/kwin/clients/ozone
    This way the external property will look for the additional files in the websvn repository. There are also kdenetwork/kget/transfer-plugins/bittorrent and kdebase/workspace/kwin/clients/ozone that use svn:externals get the url with svn propget svn:externals PATH and replace anonsvn.kde.org with websvn.kde.org:443 here too.}}
     
     
    '''qt-copy''' is a copy of the latest stable [http://www.trolltech.com Qt] release which works with KDE, put into SVN for convenience. It also contains patches by KDE developers that haven't found their way to Qt yet. They are recommended for those working with KDE from '''trunk'''. Instructions on how to get and configure it can be found [[Getting_Started/Build/Qt |here]].
     
    {{tip| It is recommended to use kde-qt.git instead of qt-copy.
     
    git clone git://gitorious.org/+kde-developers/qt/kde-qt.git qt-kde
     
    }}
     
     
    If you wish to have a complete copy of KDE TRUNK, you can simply check out the entire source tree with one command:
     
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE
     
    {{note|It is smarter to first use [http://websvn.kde.org/trunk/KDE The KDE Source Repository Web Viewer]. Use it to choose which modules to download. This way KDE will be quicker to install and try out.}}
     
    If you want additional software packages you can check out the following modules within '''trunk/''' as well:
     
    koffice
    extragear
    playground
    kdereview
     
    So, for example, if you want to check out koffice trunk, you can use:
     
    svn co svn://anonsvn.kde.org/home/kde/trunk/koffice
     
    === Checking out trunk using snapshots ===
     
    If you are checking out modules from '''trunk/''' you may be able to save time by using snapshots.  Using Subversion trunk snapshots is described at [[../Snapshots|the Subversion snapshots tutorial page]].
     
    === Checking out KDE 3 instead ===
     
    If you want to track KDE 3 rather than the bleeding edge, you may retrieve the KDE 3.5 sources using:
     
    svn co svn://anonsvn.kde.org/home/kde/branches/arts/1.5/arts
    svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/
     
    And if you want the matching qt-copy:
    svn co svn://anonsvn.kde.org/home/kde/branches/qt/3.3/qt-copy
     
    === Checking out specific releases ===
     
    KDE modules are also tagged at each release so that it is possible to get a specific release of KDE. Most KDE modules have a tag name in the format '''tags/KDE/X.Y.Z''' (where X, Y and Z represent the exact version). The arts module (only needed for KDE 2 and KDE 3) has a different format of tag name, '''tags/arts/X.Y.Z'''. For instance to get kdelibs as it was shipped in KDE 3.5.0, do:
     
    svn co svn://anonsvn.kde.org/home/kde/tags/KDE/3.5.0/kdelibs/
     
    If you then want to update this checkout to KDE 3.5.5, use this command:
     
    svn switch svn://anonsvn.kde.org/home/kde/tags/KDE/3.5.5/kdelibs
     
    {{tip|If you used a '''/branch/''' or '''/trunk/''' path, then there is no need to switch, just run '''svn update'''.}}
     
    === Checking out translations ===
    If you are looking for translations and other localizations, check out the appropriate language from the appropriate module: [http://websvn.kde.org/trunk/l10n-kde4 l10n-kde4] (KDE4) or [http://websvn.kde.org/trunk/l10n-kde3 l10n-kde3] (KDE3).
     
    {{Warning|The l10n module is ''extremely'' large. Be sure you have lots of time and disk space on hand before checking out the entire l10n module. Most people only check out specific language subdirectories rather than the entire l10n module.}}
     
    You are now ready to start building KDE! Visit [[Getting_Started/Build|this page]] for instructions on building trunk or [[Getting_Started/Build/Stable_Version|this page]] for instruction on compiling the last stable release.
     
    === Checkout from behind a proxy ===
     
    If the tip above didn't help you, and you've realized that the only way to go seems to be with http://anonsvn.kde.org/.. , then you will have to jump through a few hoops to get an svn checkout. Since http:// access is open only to developers, you will have to use svn://. Transconnect is a small piece of software that can tunnel all the traffic through your friendly neigbourhood proxy server. Get the transconnect sources from http://transconnect.sourceforge.net/ , compile it, and edit ~/.tconn/tconn.conf to point to your proxy server. Export the LD_PRELOAD variable as per the README from transconnect, and you're set to go.
     
    == Also of interest ==
    * Visit http://websvn.kde.org/ to browse the source code online.
    * anonsvn.kde.org is a round robin DNS entry, which will resolve to one out of several anonsvn mirrors. The DNS setup is maintained by [mailto:[email protected] the KDE sysadmins]. However, it might be desireable to choose a local mirror explicitely. Some mirrors are listed below, sorted by performance:
    ** kde.mneisen.org is located near Nuernberg, Germany, maintained by [mailto:[email protected] Martin Eisenhardt]
    ** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:[email protected] Adriaan de Groot]
     
    * There are also aliases anonsvn1.kde.org, anonsvn2.kde.org and anonsvn3.kde.org which point to the mirrors used in the DNS round robin (the above two plus another mneisen.org mirror). If you experience trouble because one mirror is broken, you can always select a specific mirror using either the fullnames above or simply anonsvn1, 2, or 3.


    == More information on the kde wiki ==
    : Be careful when switching between mirrors. SVN remembers the server in the working copy, so to switch you have to run
    svn switch --relocate svn://anonsvn.kde.org/ svn://kde.mneisen.org/
    : in all your checkouts.
    If you're interested in setting up a svn mirror, please contact [mailto:sysadmin@kde.org the KDE sysadmins].


    See [http://wiki.kde.org/tiki-index.php?page=KDE%20Subversion%20HOWTO the KDE wiki] for more
    [[Category:Build KDE]]
    information about subversion in KDE

    Revision as of 12:20, 13 July 2012

    Warning
    This page is yet to be reviewed for changes required by the migration to Git. Information and commands on this page may no longer be valid and should be used with care. Please see the KDE Git hub page for more details.


    Using Subversion With KDE
    Tutorial Series   Getting Started
    Previous   None
    What's Next   n/a
    Further Reading   Version Control with Subversion

    Abstract

    This is a quick KDE-specific introduction for using subversion to access files and software in KDE's repositories. For comprehensive coverage of Subversion we recommend reading the book "Version Control with Subversion".

    Getting started

    In order to use the KDE Subversion repository, you will need a Subversion client program.

    If you only need SVN for checking out the sources (read-only), use the protocol: "svn" at the server: "anonsvn.kde.org".

    So for example, instead of what you see throughout this tutorial, your paths would show a similarity to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

    Note: Wherever it mentions "yourname@", http, https, or passwords, you should ignore those and use what is mentioned. None of that stuff is needed for the anonymous server.

    If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: get an SVN Account.


    Installing Subversion: instructions on installing the client are not presented here. Refer to your system installation instructions to find out how you can install Subversion. You will need version 1.1 at least. If you are compiling from sources and want to access the KDE repository by https (and not by svn+ssh), you will need SSL and ZLIB support, so you will need the --with-ssl --with-zlib options.

    Alternatively, you can install one of the many graphical clients out there(for example, kdesvn, albeit unofficial). This tutorial is intended for people using the svn program only, referring to tasks accomplished with the usual cvs program.

    Getting an account: if you have had a CVS account before, it has been migrated to the new Subversion client.

    The KDE repository structure

    svn.kde.org/home/kde
    

    That's the address of the KDE Subversion repository. The repository is served by HTTPS or SVN+SSH protocol, which means your password is secure against third-party eavesdropping.

    The SSL certificate md5 fingerprint for the repositories:

    F6BF EDE2 D016 D1B2   4F18 742E 2C8F B7EF
    

    The SSL certificate sha1 fingerprint for the repositories:

    e1:e6:41:96:3c:eb:ae:78:e2:73:0d:a2:32:2f:6b:21:13:bf:3d:0f
    

    For people using svn+ssh, here's the fingerprint of the server's RSA key:

    1e:89:fa:0d:c3:11:a4:81:36:84:b6:f2:6b:f0:5b:ad
    

    The repository is organised in main directories:

    1. /branches
    2. /tags
    3. /trunk

    You can explore the repository structure at http://websvn.kde.org/


    The top-level directory /trunk

    The /trunk top-level subdirectory is where the main development for KDE occurs. What you will find here is what will become the next KDE release and its associated programs. Here you will also find the www module, which contains webpages for KDE's site and related ones.

    /trunk is further subdivided into these sub-directories:

    • KDE/
      KDE itself, what will become the next public release. It contains the following modules:
      • kdelibs - KDE basic libraries, used by all KDE programs
      • kdebase - KDE base programs, like the KDE Control Center, Kicker (the panel) and Konqueror (the web browser)
      • kdeaccessibility - Accessibility files
      • kdeadmin - KDE Administration applications
      • kdeartwork - Images, themes, sounds and other art files
      • kdebindings - Bindings for languages other than C++
      • kdeedu - KDE Educational applications
      • kdegames - KDE Games
      • kdegraphics - KDE Graphical applications
      • kdemultimedia - KDE Multimedia applications
      • kdenetwork - KDE Networking applications
      • kdepim - KDE Personal Information Management applications
      • kdepimlibs - Libraries used by KDE-PIM applications.
      • kdesdk - KDE Software Development Kit applications
      • kdetoys - KDE toy applications
      • kdeutils - KDE General utilities
      • kdewebdev - KDE Web development applications
    • kde-common
    Common admin/ directory
    • bugs/
    Bugzilla files
    • developer.kde.org/
    The content of developer.kde.org
    • extragear/
    KDE programs outside the main KDE releases.
    • kdereview/
    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 /trunk/KDE/ or to /trunk/extragear/
    • kdesupport/
    Supporting applications and libraries for KDE
    • koffice/
      The KDE Office suite, containing the programs:
      • karbon
      • kchart
      • kexi
      • kformula
      • kivio
      • koshell
      • kplato
      • kpresenter
      • krita
      • kspread
      • kword
    • konstruct/
    Konstruct, the KDE build program
    • l10n-kde3/
    Translations for the "unstable" modules of KDE 3 (extragear, playground)
    • l10n-kde4/
    Translations for KDE 4
    • playground/
    The KDE playground: applications being developed, but not having yet reached release-quality.
    • qt-copy/
    The convenience copy of Trolltech's Qt library, which KDE is based upon. Remember, this is deprecated, you should be using the git repository, kde-qt instead. Qt-copy is at version 4.5, yet trunk requires
    • tests/
    khtml, KOffice and ksvg testcases
    • valgrind/
    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.
    • www/
    Webpages for the KDE site (and related sites). Write access to this directory is restricted.

    The top-level directory /tags

    This directory contains the official releases of the programs maintained and developed in the KDE repository. Each individual application has a subdirectory here. Inside it, you will find the release numbers.

    For instance, the KDE 3.4.0 code can be found under /tags/KDE/3.4.0/.

    The top-level directory /branches

    This directory contains the branch versions of the applications after a major release.

    Most KDE applications adhere to the philosphy that new features (as well as new user-visible strings) are added only to the next release cycle — the one that lives in /trunk/. However, bugfixes are applied to all applications, even after release.

    In order to do that, a branch is created at the moment of the release, indicating the state of the files at that time. Bugfixes are then checked in to those files. Those branches are the ones in /branches/.

    For instance, the KDE 3.4.x branch can be found under /branches/KDE/3.4/

    The subdirectories you will find inside /branches are the application subdirs, like akregator/, amarok/, arts/, k3b/, etc. You will also find a KDE/ subdir, containing the official KDE releases since time immemorial.

    One special subdir is found in /branches: work/. This subdir contains the so-called "work branches", that is, branches containing features being worked on, sometimes highly experimental. Multi-application work branches always are checked in to /branches/work/, but single-application branches may be found in each application's subdir. That is a decision left to the developers.


    Checking out and updating

    Checking out

    In order to check out something with Subversion, you use the checkout subcommand.

    WARNING: If you checkout trunk/KDE/ or branches/KDE/foo/ you will download complete kde-i18n!

    Suppose you wanted to check out only kdeedu from the KDE repository. You would do:

    Subversion users currently using ssh access should use protocol svn+ssh while subversion users currently using password access should use protocol https in the following:

    svn checkout --username=<username> <protocol>://svn.kde.org/home/kde/trunk/KDE/kdeedu
    

    For checking out kdevelop from extragear you would do:

    svn checkout --username=<username> <protocol>://svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop
    

    Note that you may wish to use the following if the above doesn't work:

    svn checkout <protocol>://<username>@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop
    

    Updating

    In order to update, you use the update subcommand.

    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.

    Knowing the status of a file

    To know which local files you had modified, you have to do

    svn status
    

    and look at the files with M (for modified).

    Committing to the repository

    Committing to the Subversion repository is accomplished with the commit (ci for short) subcommands:

    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 option with your full message:

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

    Ignoring files

    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):

    global-ignores = *.o *.lo *.la .*.rej *.rej .*~ *~ .#* #*# .DS_Store *.moc
    *.moc.cc *.moc.cpp config.log config.status config.cache *.gmo .deps .libs
    SunWS_cache *.lo *.la *.rpo *.la.closure *_la_closure.cpp *_la_closure.cc
    *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp *.all_C.C *.all_cxx.cxx
    *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp *_meta_unload.C
    *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in Makefile.calls.in
    Makefile.rules Makefile.calls autom4te.cache *.kidl
    

    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:

    1. 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.
    2. You modify file README and commit it. Suppose Subversion tells you it committed revision 403822. This means HEAD, BASE and COMMITTED are 403822.
    3. 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).
    4. 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)
    5. 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.

    Linking in subdirectories from other places

    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

    svn propedit svn:externals .
    

    and then enter lines of the form

    libkhalkhi svn://anonsvn.kde.org/home/kde/trunk/playground/pim/khalkhi
    

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

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


    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

    admin https://svn.kde.org/home/kde/branches/KDE/3.5/kde-common/admin
    

    there is no need to change this.

    Further Links

    Old Getting_started/Sources/Anonymous SVN Page

    Abstract

    For those of us that like to stay on the "bleeding edge" there's an easy way to keep a local copy of the KDE sources up-to-date — anonymous SVN.

    Alternatively, install KDE SVN packages from your distribution.

    Anonymous SVN

    Setup Subversion

    First, install the subversion (svn) binary if it isn't already on your computer. Your operating system should have a package for it. Alternatively you can download and compile it yourself via the svn project download page. Please read the KDE Subversion tutorial if you are interested in how to use Subversion.

    Checkout KDE TRUNK

    /trunk/ is where the Qt4-based KDE 4 is being developed. The following is the minimal set of modules you will need to check out to build KDE and KDE software:

    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdepimlibs
    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE/kdebase
    

    You also need to checkout KDESupport:

    svn co svn://anonsvn.kde.org/home/kde/trunk/kdesupport
    
    Tip
    If your firewall doesn't allow access to arbitrary ports, substitute svn://anonsvn.kde.org/ with svn://anonsvn4.kde.org:443/ above.


    Tip
    The kdebase module has an external dependency, using svn:externals. The problem is, at this time, the externals property is set with an absolute path, pointing to anonsvn. For those using behind a firewall, this is a problem. You can change the property for your workspace, using two commands:
    cs KDE
    svn propset svn:externals "lib svn://websvn.kde.org:443/home/kde/trunk/KDE/kdebase/runtime/kstyles/oxygen/lib" kdebase/workspace/kwin/clients/oxygen 
    svn propset svn:externals "lib svn://websvn.kde.org:443/home/kde/trunk/KDE/kdebase/runtime/kstyles/oxygen/lib" kdebase/workspace/kwin/clients/ozone
    
    This way the external property will look for the additional files in the websvn repository. There are also kdenetwork/kget/transfer-plugins/bittorrent and kdebase/workspace/kwin/clients/ozone that use svn:externals get the url with svn propget svn:externals PATH and replace anonsvn.kde.org with websvn.kde.org:443 here too.


    qt-copy is a copy of the latest stable Qt release which works with KDE, put into SVN for convenience. It also contains patches by KDE developers that haven't found their way to Qt yet. They are recommended for those working with KDE from trunk. Instructions on how to get and configure it can be found here.

    Tip
    It is recommended to use kde-qt.git instead of qt-copy. git clone git://gitorious.org/+kde-developers/qt/kde-qt.git qt-kde


    If you wish to have a complete copy of KDE TRUNK, you can simply check out the entire source tree with one command:

    svn co svn://anonsvn.kde.org/home/kde/trunk/KDE
    
    Note
    It is smarter to first use The KDE Source Repository Web Viewer. Use it to choose which modules to download. This way KDE will be quicker to install and try out.


    If you want additional software packages you can check out the following modules within trunk/ as well:

    koffice
    extragear
    playground
    kdereview
    

    So, for example, if you want to check out koffice trunk, you can use:

    svn co svn://anonsvn.kde.org/home/kde/trunk/koffice
    

    Checking out trunk using snapshots

    If you are checking out modules from trunk/ you may be able to save time by using snapshots. Using Subversion trunk snapshots is described at the Subversion snapshots tutorial page.

    Checking out KDE 3 instead

    If you want to track KDE 3 rather than the bleeding edge, you may retrieve the KDE 3.5 sources using:

    svn co svn://anonsvn.kde.org/home/kde/branches/arts/1.5/arts
    svn co svn://anonsvn.kde.org/home/kde/branches/KDE/3.5/
    

    And if you want the matching qt-copy:

    svn co svn://anonsvn.kde.org/home/kde/branches/qt/3.3/qt-copy
    

    Checking out specific releases

    KDE modules are also tagged at each release so that it is possible to get a specific release of KDE. Most KDE modules have a tag name in the format tags/KDE/X.Y.Z (where X, Y and Z represent the exact version). The arts module (only needed for KDE 2 and KDE 3) has a different format of tag name, tags/arts/X.Y.Z. For instance to get kdelibs as it was shipped in KDE 3.5.0, do:

    svn co svn://anonsvn.kde.org/home/kde/tags/KDE/3.5.0/kdelibs/
    

    If you then want to update this checkout to KDE 3.5.5, use this command:

    svn switch svn://anonsvn.kde.org/home/kde/tags/KDE/3.5.5/kdelibs
    
    Tip
    If you used a /branch/ or /trunk/ path, then there is no need to switch, just run svn update.


    Checking out translations

    If you are looking for translations and other localizations, check out the appropriate language from the appropriate module: l10n-kde4 (KDE4) or l10n-kde3 (KDE3).

    Warning
    The l10n module is extremely large. Be sure you have lots of time and disk space on hand before checking out the entire l10n module. Most people only check out specific language subdirectories rather than the entire l10n module.


    You are now ready to start building KDE! Visit this page for instructions on building trunk or this page for instruction on compiling the last stable release.

    Checkout from behind a proxy

    If the tip above didn't help you, and you've realized that the only way to go seems to be with http://anonsvn.kde.org/.. , then you will have to jump through a few hoops to get an svn checkout. Since http:// access is open only to developers, you will have to use svn://. Transconnect is a small piece of software that can tunnel all the traffic through your friendly neigbourhood proxy server. Get the transconnect sources from http://transconnect.sourceforge.net/ , compile it, and edit ~/.tconn/tconn.conf to point to your proxy server. Export the LD_PRELOAD variable as per the README from transconnect, and you're set to go.

    Also of interest

    • Visit http://websvn.kde.org/ to browse the source code online.
    • anonsvn.kde.org is a round robin DNS entry, which will resolve to one out of several anonsvn mirrors. The DNS setup is maintained by the KDE sysadmins. However, it might be desireable to choose a local mirror explicitely. Some mirrors are listed below, sorted by performance:
      • kde.mneisen.org is located near Nuernberg, Germany, maintained by Martin Eisenhardt
      • www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by Adriaan de Groot
    • There are also aliases anonsvn1.kde.org, anonsvn2.kde.org and anonsvn3.kde.org which point to the mirrors used in the DNS round robin (the above two plus another mneisen.org mirror). If you experience trouble because one mirror is broken, you can always select a specific mirror using either the fullnames above or simply anonsvn1, 2, or 3.
    Be careful when switching between mirrors. SVN remembers the server in the working copy, so to switch you have to run
    svn switch --relocate svn://anonsvn.kde.org/ svn://kde.mneisen.org/
    
    in all your checkouts.

    If you're interested in setting up a svn mirror, please contact the KDE sysadmins.