KDE TechBase - User contributions [en]

Getting Started/Sources/Subversion

2013-01-28T22:49:53Z

Toma: /* Checking out */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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.

=== Checkout behind a Firewall ===
If you are behind a firewall and port 22 is blocked, you can do the following if https traffic is allowed:

Add the following to your .ssh/config:

Host sshsvn.kde.org
Port 443

Use sshsvn.kde.org as hostname, for example try:

svn ls svn+ssh://yourusername@sshsvn.kde.org/home/kde
Warning: the hostname sshsvn.kde.org will only work in this particular case. Use svn.kde.org if you are not using the above setup.

== Also of interest ==
* Visit http://websvn.kde.org/ to browse the source code online.
* anonsvn.kde.org is made up out of multiple servers spread over the world.

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:38:11Z

Toma: /* Firewall */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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.

=== Checkout behind a Firewall ===
If you are behind a firewall and port 22 is blocked, you can do the following if https traffic is allowed:

Add the following to your .ssh/config:

Host sshsvn.kde.org
Port 443

Use sshsvn.kde.org as hostname, for example try:

svn ls svn+ssh://yourusername@sshsvn.kde.org/home/kde
Warning: the hostname sshsvn.kde.org will only work in this particular case. Use svn.kde.org if you are not using the above setup.

== Also of interest ==
* Visit http://websvn.kde.org/ to browse the source code online.
* anonsvn.kde.org is made up out of multiple servers spread over the world.

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:37:49Z

Toma: /* Firewall */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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.

=== Firewall ===
If you are behind a firewall and port 22 is blocked, you can do the following if https traffic is allowed:

Add the following to your .ssh/config:

Host sshsvn.kde.org
Port 443

Use sshsvn.kde.org as hostname, for example try:

svn ls svn+ssh://yourusername@sshsvn.kde.org/home/kde
Warning: the hostname sshsvn.kde.org will only work in this particular case. Use svn.kde.org if you are not using the above setup.

== Also of interest ==
* Visit http://websvn.kde.org/ to browse the source code online.
* anonsvn.kde.org is made up out of multiple servers spread over the world.

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:36:16Z

Toma:

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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.

=== Firewall ===
If you are behind a firewall and port 22 is blocked, you can do the following if https traffic is allowed:

Add the following to your .ssh/config:

Host sshsvn.kde.org
Port 443

Use sshsvn.kde.org as hostname, for example try:

svn ls svn+ssh://yourusername@sshsvn.kde.org/home/kde
Warning: the hostname sshsvn.kde.org will only work in this particular case. Use svn.kde.org if you are not using the above setup.

Anonsvn is available via port 443 on the anonsvn4 hostname:
svn ls svn://anonsvn4.kde.org:443/home/kde

== Also of interest ==
* Visit http://websvn.kde.org/ to browse the source code online.
* anonsvn.kde.org is made up out of multiple servers spread over the world.

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:16:00Z

Toma: /* Also of interest */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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 made up out of multiple servers spread over the world.

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:14:53Z

Toma: /* Linking in subdirectories from other places */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <tt>svn log</tt> command.

=== 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:14:11Z

Toma: /* Further Links */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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.

=== 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:13:47Z

Toma: /* Old Getting_started/Sources/Anonymous SVN Page */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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]]

=== 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:13:07Z

Toma: /* Setup Subversion */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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 =

== Anonymous SVN ==

=== 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.}}

=== 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:12:48Z

Toma: /* Checking out trunk using snapshots */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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 =

== 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.}}

=== 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:12:14Z

Toma: /* Abstract */

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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 =

== 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.}}

=== 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 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:10:15Z

Toma:

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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.}}

=== 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 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:08:37Z

Toma:

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE. Also note that Subversion is currently being dismantled. See [http://community.kde.org/Sysadmin/SVNInfrastructureShutdown this timeline]

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<tt>qt-copy/</tt>

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

:khtml, KOffice and ksvg testcases

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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.}}

=== 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 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Getting Started/Sources/Subversion

2013-01-26T20:05:34Z

Toma: Updates

{{TutorialBrowser|
series=Getting Started|
name=Using Subversion With KDE|
reading=[[Contribute/Send Patches|Contributing/Sending Patches]]|
reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

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]".

Please see the [[Development/Git|KDE Git page]] for more details about git within KDE.

== 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 be similar to this: svn://anonsvn.kde.org/home/kde/trunk/KDE/kdevelop

If you would like to commit changes to the repository, you will need an SVN account, which is obtainable here: [[Get a SVN Account|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 <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

That's the address of the KDE Subversion repository.

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:

#/branches
#/tags
#/trunk

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

 

=== The top-level directory /trunk ===

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> 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>bugs/</tt>

:[http://bugs.kde.org/ Bugzilla] files

*<tt>developer.kde.org/</tt>

:The content of developer.kde.org

*<tt>extragear/</tt>

:KDE programs outside the main KDE releases.

*<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>

*<tt>kdesupport/</tt>

:Supporting applications and libraries for KDE

*<tt>koffice/</tt> The KDE Office suite, containing the programs:
**'''karbon'''
**'''kchart'''
**'''kexi'''
**'''kformula'''
**'''kivio'''
**'''koshell'''
**'''kplato'''
**'''kpresenter'''
**'''krita'''
**'''kspread'''
**'''kword'''
*<tt>konstruct/</tt>

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

:The KDE playground: applications being developed, but not having yet reached release-quality.

*<tt>qt-copy/</tt>

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

:khtml, KOffice and ksvg testcases

*<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>

:Webpages for the KDE site (and related sites). Write access to this directory is restricted.

=== 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 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 <tt>/trunk/</tt>. 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 <tt>/branches/</tt>.

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

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.

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.

 

== Checking out and updating ==

=== Checking out ===

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!

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 svn+ssh:://username@svn.kde.org/home/kde/trunk/KDE/kdeedu

For checking out kdevelop from extragear you would do:

svn checkout svn+ssh://username@svn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

If you don't have a KDE developers account, use:

svn checkout svn:://anonsvn.kde.org/home/kde/trunk/extragear/sdk/kdevelop

=== Updating ===

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.

== 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 <tt>commit</tt> (<tt>ci</tt> for short) subcommands:

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

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:

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 {{path|~/.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 <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 <tt>-r</tt> 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 <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.
#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 <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.}}

=== 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 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. 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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org Adriaan de Groot]

[[Category:Build KDE]]

Schedules

2011-02-08T20:21:56Z

Toma: /* KDE4 */

__NOTOC__

During development, the KDE project sets goals in features and dates for upcoming releases. This way, the team knows when it would be a good time to add a new feature or when it's time to
focus on cleaning up any bugs in preparation for a release. Any plans are tentative schedules and the final dates are generally decided on the kde-core-devel mailing list.

Learn more about [[Schedules/Release Schedules Guide|release schedules]].

== KDE4 ==
* [[Schedules/KDE4/Goals|KDE 4 Goals]]
* [[Schedules/KDE4/Application Porting Status|Application Porting Status]]

*'''KDE SC 4.7'''
** [[Schedules/KDE4/4.7 Release Schedule|Release Schedule]]

*'''KDE SC 4.6'''
** [[Schedules/KDE4/4.6 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.6 Feature Plan|Feature Plan]]

*'''KDE SC 4.5'''
** [[Schedules/KDE4/4.5 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.5 Feature Plan|Feature Plan]]

*'''KDE SC 4.4'''
** [[Schedules/KDE4/4.4 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.4 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.4 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.4 for you?|Is KDE 4.4 for you?]]
** [[Schedules/KDE4/4.4 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.4 Requirements|Compilation Requirements]]

*'''KDE 4.3'''
** [[Schedules/KDE4/4.3 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.3 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.3 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.3 for you?|Is KDE 4.3 for you?]]
** [[Schedules/KDE4/4.3 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.3 Requirements|Compilation Requirements]]

*'''KDE 4.2'''
** [[Schedules/KDE4/4.2 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.2 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.2 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.2 for you?|Is KDE 4.2 for you?]]
** [[Schedules/KDE4/4.2 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.2 Requirements|Compilation Requirements]]

*'''KDE 4.1'''
** [[Schedules/KDE4/4.1 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.1 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.1 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.1 for you?|Is KDE 4.1 for you?]]

*'''KDE 4.0'''
** [[Schedules/KDE4/4.0 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.0 Release Roadmap|Release Milestones]]
** [[Schedules/KDE4/4.0 Module_Status|Module Status and Pending Application Issues]]
** [[Schedules/KDE4/4.0 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.0 Announcements|Announcement Information]]
** [http://developer.kde.org/development-versions/kde-4.0-features.html Feature Plan]
** [[Schedules/KDE4/4.0 Requirements|Compilation Requirements]]

== KDE3 ==

*'''KDE 3.5''' [[Schedules/KDE 3.5 Release Schedule|release schedule]], [[Schedules/KDE 3.5 Feature Plan|feature plan]]

=== Previous releases ===

*'''KDE 3.4''' [[Schedules/KDE 3.4 Release Schedule|release schedule]], [[Schedules/KDE 3.4 Feature Plan|feature plan]]
*'''KDE 3.3''' [[Schedules/KDE 3.3 Release Schedule|release schedule]], [[Schedules/KDE 3.3 Feature Plan|feature plan]]
*'''KDE 3.2''' [[Schedules/KDE 3.2 Release Schedule|release schedule]], [[Schedules/KDE 3.2 Feature Plan|feature plan]]
*'''KDE 3.1''' [[Schedules/KDE 3.1 Release Schedule|release schedule]], [[Schedules/KDE 3.1 Feature Plan|feature plan]]
*'''KDE 3.0''' [[Schedules/KDE 3.0 Release Schedule|release schedule]], [[Schedules/KDE 3.0 Feature Plan|feature plan]]

== KOffice ==

=== Current releases ===

*'''KOffice 2.3''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.3/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.3/Feature_Plan feature plan]
*'''KOffice 2.2''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.2/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.2/Feature_Plan feature plan]
*'''KOffice 2.1''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Feature_Plan feature plan]
*'''KOffice 2.0''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.0/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.0/Feature_Plan feature plan]

=== Previous releases ===

*'''KOffice 1.6''' [[Schedules/KOffice 1.6 Release Schedule|release schedule]]
*'''KOffice 1.5''' [[Schedules/KOffice 1.5 Release Schedule|release schedule]]

== Extragear ==
* [[Schedules/Extragear|Overview of upcoming Extragear releases]]

== Playground ==
* [[Schedules/Playground|Overview of upcoming Playground releases]]

Schedules/KDE4/4.7 Release Schedule

2011-02-08T20:21:32Z

Toma: Created page with 'KDE SC 4.7 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting ...'

KDE SC 4.7 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

You can also add [http://www.kde.org/releaseschedule.ics http://www.kde.org/releaseschedule.ics] as remote calendar to korganizer so you always have the release schedule near you.

== KDE SC 4.7 ==

=== Thursday, April 28, 2011: KDE 4.7 Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, May 12, 2011: KDE 4.7 Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. You cannot add new strings, if you really need one ask kde-i18n-doc for an exception. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until the Hard Message Freeze, but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, May 12, 2011: KDE 4.7 Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, May 12, 2011: KDE 4.7 Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, May 12, 2011: KDE 4.7 Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, May 19, 2011: KDE 4.7 Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, May 25, 2011: KDE 4.7 Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, May 30, 2011: KDE 4.7 Documentation Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, June 2, 2011: KDE 4.7 Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, June 8, 2011: KDE 4.7 Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, June 20, 2011: KDE 4.7 Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, June 20, 2011: KDE 4.7 Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, June 20, 2011: KDE 4.7 Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need to contact kde-i18n-doc for every single string change, if noone objects in 5 days you can commit the change.

=== Monday, June 20, 2011: KDE 4.7 Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, June 21, 2011: KDE 4.7 Release Candidate 1 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, June 22, 2011: KDE 4.7 Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, July 4, 2011: KDE 4.7 Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, July 5, 2011: KDE 4.7 Release Candidate 2 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, July 6, 2011: KDE 4.7 Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, July 20, 2011: KDE 4.7 Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, July 27, 2011: KDE 4.7 Release ===
Final release is released for general consumption.

=== Thursday, September 1, 2011: KDE 4.7.1 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, September 6, 2011: KDE 4.7.1 release ===
A KDE minor release is released to the public.

=== Thursday, September 29, 2011: KDE 4.7.2 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, October 4, 2011: KDE 4.7.2 release ===
A KDE minor release is released to the public.

=== Thursday, October 27, 2011: KDE 4.7.3 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, November 1, 2011: KDE 4.7.3 release ===
A KDE minor release is released to the public.

=== Thursday, December 1, 2011: KDE 4.7.4 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, December 6, 2011: KDE 4.7.4 release ===
A KDE minor release is released to the public.

Schedules/KDE4/4.6 Release Schedule

2011-02-08T20:00:50Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

You can also add [http://www.kde.org/releaseschedule.ics http://www.kde.org/releaseschedule.ics] as remote calendar to korganizer so you always have the release schedule near you.

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: KDE 4.6 Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: KDE 4.6 Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. You cannot add new strings, if you really need one ask kde-i18n-doc for an exception. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until the Hard Message Freeze, but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: KDE 4.6 Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: KDE 4.6 Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: KDE 4.6 Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: KDE 4.6 Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: KDE 4.6 Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: KDE 4.6 Documentation Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: KDE 4.6 Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: KDE 4.6 Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: KDE 4.6 Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: KDE 4.6 Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: KDE 4.6 Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need to contact kde-i18n-doc for every single string change, if noone objects in 5 days you can commit the change.

=== Monday, December 20, 2010: KDE 4.6 Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: KDE 4.6 Release Candidate 1 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: KDE 4.6 Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: KDE 4.6 Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: KDE 4.6 Release Candidate 2 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: KDE 4.6 Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: KDE 4.6 Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: KDE 4.6 Release ===
Final release is released for general consumption.

=== Thursday, February 24, 2011: KDE 4.6.1 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, March 1, 2011: KDE 4.6.1 release ===
A KDE minor release is released to the public.

=== Thursday, March 31, 2011: KDE 4.6.2 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, April 5, 2011: KDE 4.6.2 release ===
A KDE minor release is released to the public.

=== Thursday, April 28, 2011: KDE 4.6.3 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, May 3, 2011: KDE 4.6.3 release ===
A KDE minor release is released to the public.

=== Thursday, June 2, 2011: KDE 4.6.4 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, June 7, 2011: KDE 4.6.4 release ===
A KDE minor release is released to the public.

=== Thursday, June 30, 2011: KDE 4.6.5 tagging ===
A KDE minor release is tagged and made available to the packagers.

=== Tuesday, July 5, 2011: KDE 4.6.5 release ===
A KDE minor release is released to the public.

Schedules/KDE4/4.6 Release Schedule

2011-01-01T20:45:24Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

You can also add [http://www.kde.org/releaseschedule.ics http://www.kde.org/releaseschedule.ics] as remote calendar to korganizer so you always have the release schedule near you.

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. You cannot add new strings, if you really need one ask kde-i18n-doc for an exception. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until the Hard Message Freeze, but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentation Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need to contact kde-i18n-doc for every single string change, if noone objects in 5 days you can commit the change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Branch is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-11-28T16:01:03Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

You can also add [http://www.kde.org/releaseschedule.ics http://www.kde.org/releaseschedule.ics] as remote calendar to korganizer so you always have the release schedule near you.

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until the Hard Message Freeze, but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need to contact kde-i18n-doc for every single string change, if noone objects in 5 days you can commit the change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Getting Started/Sources/Anonymous SVN

2010-11-06T18:01:54Z

Toma: /* Checkout KDE TRUNK */

{{Template:I18n/Language Navigation Bar|Getting Started/Sources/Anonymous SVN}}
{{TutorialBrowser|

series=Getting Started|

name=Getting KDE Sources Using Anonymous Subversion (SVN)|

next=[[../../Build/KDE4|Building KDE4]]|

reading=[http://svnbook.red-bean.com/ Version Control with Subversion]|
}}

== 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/KDE4/Prerequisites#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/KDE4|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:sysadmin@kde.org 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:martin.eisenhardt@mneisen.org Martin Eisenhardt]
** www.englishbreakfastnetwork.org also hosts an anonymous SVN mirror, at the University of Nijmegen, Netherlands. Maintained by [mailto:groot@kde.org 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 [mailto:sysadmin@kde.org the KDE sysadmins].

[[Category:Build KDE]]

Projects/MovetoGit

2010-10-25T11:17:48Z

Toma: /* post-update hooks */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|100}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|100}}
'''Owner:''' sysadmin
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''
:sysadmin will add mirrors as needed and is prepared for it. -- toma

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|50|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

Neverendingo is looking at this as needed --toma

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|100}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

Working fine in the new setup, --toma

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MovetoGit

2010-10-25T11:16:52Z

Toma: /* Account setup for Gitolite */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|100}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|100}}
'''Owner:''' sysadmin
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''
:sysadmin will add mirrors as needed and is prepared for it. -- toma

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|50|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

Neverendingo is looking at this as needed --toma

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|100}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|90}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MovetoGit

2010-10-25T11:16:21Z

Toma: /* Website Branding */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|100}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|100}}
'''Owner:''' sysadmin
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''
:sysadmin will add mirrors as needed and is prepared for it. -- toma

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|50|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

Neverendingo is looking at this as needed --toma

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|0}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|90}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MovetoGit

2010-10-25T11:15:32Z

Toma: /* Setup git mirrors for cloning */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|100}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|100}}
'''Owner:''' sysadmin
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''
:sysadmin will add mirrors as needed and is prepared for it. -- toma

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|2|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|0}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|90}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MovetoGit

2010-10-25T11:14:28Z

Toma: /* Snapshot to read-only svn */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|100}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

Scripty operates on a git clone of the repo's. No need for this item imho -- toma

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|0}}
'''Owner:''' No one (help!)
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|2|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|0}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|90}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MovetoGit

2010-10-25T11:11:56Z

Toma: /* Setup git.kde.org */

This is the page for co-ordinating KDE's move to [http://git-scm.com/ Git].

If you're interested in helping, you should join the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest@kde.org] mailinglist and [irc://chat.freenode.net/kde-git #kde-git] on freenode.

Meetings are wednesdays, 19:30 UTC, in #kde-git.

'''New! [http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting The best way you can help us migrate]'''

=The Plan=

KDE is, eventually, moving to Git. We will be using gitolite + Redmine + reviewboard on our own servers.

In the summer of 2009, [http://gitorious.org/amarok Amarok] moved to Gitorious to test the waters and find problems that would affect KDE.

After it has been decided in Jun 2010 to use our own servers, Amarok and Konversation moved to git.kde.org/projects.kde.org to test the waters and find problems that would affect KDE.

Once those problems have been solved, all of KDE will be able to switch.

A full schedule for the git infrastructure can be found [http://community.kde.org/Sysadmin/GitInfrastructureLaunch here].

==Why?==

Git offers many advantages over svn, including offline commits and much easier to keep a feature branch up-to-date. Many KDE developers are already using git-svn, but this tool has its limitations. We want to have the full power of Git available, and we have people willing to do the work necessary to migrate.

==How?==

When we move, KDE's svn repository will be migrated into several Git repos, all on git.kde.org. Main modules such as kdelibs and kdebase will each become one repository. Projects in extragear will each have their own repository. The projects.kde.org site will have a list (lists?) of all these repositories using the redmine project wiki. Scripts will be provided for downloading, say, all of extragear, so "moving" a project from kdereview to extragear would simply involve editing a file kept online that defined the location of projects.
Details on the reasoning behind this layout is available [[Projects/MoveToGit/Layout|here]].

A few things will stay in subversion - currently websites, translations and manuals. It's possible they could move to Git later, but they won't be part of the mass migration.

All KDE developers will in principle be able to use their existing "svn" accounts. Developers using HTTPS ideally would request their HTTPS SVN account to be converted to SSH as that makes it easiest for the KDE sysadmins, but alternatively they can also just provide a public key. At some point the KDE sysadmins are going to send everybody with a HTTPS SVN account an email with a link to a web app to collect their key (see http://www.omat.nl/2010/06/13/sysamin-update-your-email-address/).

From the times when gitorious.org was the preferred hosting solution, a procedure to move a project from svn to gitorious.org can be found in [[Projects/MoveToGit/StepsToMove|Steps to follow for Moving]].
Many points probably still apply, but have to be updated.

=Blockers=

Tasks that need to get done before we can migrate

==Setup git.kde.org==
{{Progress bar|100}}
'''Owner:''' Eike, Jeff, Sysadmin team

'''Status:''' ''Progressing''

: It [http://lists.kde.org/?l=kde-scm-interest&m=127612957219466&w=2 has been decided] to use gitolite + Redmine + reviewboard on our own servers rather than gitorious.org. Sysadmin team is preparing git.kde.org for this.

==Write / update importing rules for svn2git==
{{Progress bar|5}}
'''Owner:''' see below - volunteers needed!

'''Status:''' ''sho: ???, tumaix:started to read the docs, cryos: getting started [2010-01-06]''

:The importer is on gitorious.org as svn2git we have a set of rules to tell the importer what svn dirs turn into which git repos and those need constant updating whenever a new branch or tag or project is created. Currently the rules are mostly a rough draft, as seen by the large amount of rule-editing that had to be done for Konversation and Amarok. This has not been done for quite some time and so someone should rsync the svn repo run svn2git and fix the rules and importer whenever the import stops.

:This is a very big task, too big for one person; it's probably best to tackle it one module at a time

:To get started on a module, read [[Projects/MoveToGit/UsingSvn2Git|Using Svn2Git]]

:TZander has done the koffice ruleset as of 2009-01-06

:Jpwhiting has finished (more or less) the kdeaccessibility ruleset 2010-01-24.

:aavci has done the k3b ruleset as of 2010-01-27

progress details:
{| border="1"
!repo
!owner
!%
!comments
|-
|SC/kdeaccessibility
|jpwhiting
|99
|"more or less"?
|-
|SC/kdeadmin
|
|0
|
|-
|SC/kdeartwork
|
|0
|
|-
|SC/kdebase
|
|0
|
|-
|SC/kdebindings
|pumphaus/Arno Rehn
|90
|Includes nearly everything; some history from playground might be missing. Some tags from the CVS days don't have a parent yet - still have to figure out why.
|-
|SC/kdeedu
|cryos?
|?
|update me!
|-
|SC/kdeedu/marble
|jmho
|100
|Contains: trunk with moves (playground->kdereview->kdeedu), regular kde branches/tags and the following other branches: marble-0.4, gsoc-2009 and geodata-nt. Checking done: gitk --all, verify-git-from-svn
|-
|SC/kdeexamples
|
|0
|
|-
|SC/kdegames
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdegraphics
|
|0
|
|-
|SC/kdelibs
|
|0
|
|-
|SC/kdemultimedia
|eean
|0
|
|-
|SC/kdenetwork
| grundleborg
|0
|
|-
|SC/kdepim
|tnyblom
|95
|Needs verification.
|-
|SC/kdepim-runtime
|tnyblom
|95
|Needs verification.
|-
|SC/kdepimlibs
|tnyblom
|95
|Needs verification.
|-
|SC/kdeplasma-addons
|
|0
|
|-
|SC/kdesdk
|
|0
|
|-
|SC/kdetoys
|
|0
|
|-
|SC/kdeutils
|jobermayr
|95
|coolo or mueller do not give me required information for old tags :-(
|-
|SC/kdewebdev
|
|0
|
|-
|extragear/sdk/kdevelop
| apaku
| 95
| trunk and branches complete, need to cleanup tags from cvs days.
|-
|extragear/sdk/kdevplatform
| apaku
| 100
| done, all tags seem fine all branches are there
|-
|extragear/sdk/kdevelop-plugins
| nsams
| 100
| done
|-
|extragear/sdk/quanta
| nsams
| 99
| done
|-
|extragear/utils/krecipes
| santa
| 85
| Branches are done, I'm working on tags.
|-
|extragear/*/*
|
|xx
|expand the *'s later (let's focus on the base modules first)
|-
|kde-common
|mattr
|75
|analyzing import history
|-
|kdesupport
|
|0
|
|-
|kdesupport/akonadi
|cgiboudeaux
|95
|In progress...
|-
|koffice
|tzander
|85
|All but tags are done
|-
|promo
|
|0
|
|-
|quality
|
|0
|
|-
|tests
|
|0
|
|}

== Requirements of KDEPIM and KDAB ==

{{Progress bar|90}}
'''Owner:''' Stephen Kelly

'''Status:''' ''Proposed workflow identified. Partially depends on KDE policies regarding branches and merging. Gathering estimates for porting of tooling from svn to git. People unfamiliar with the tool are starting to learn to use it.''

'''Estimated completion date''': End of May.

'''Summary of issues'''

* Clean slate
** The existing backlog of commits which need to be merged or ported to trunk needs to be empty before the change to git so that nothing gets lost. This is a lot of work and will take time. ''Estimate'' 10 calendar weeks.
* Technical difficulties and limitations.
** Up to KDE 3.5 there was one kdepim module. For the KDE4 cycle, this was split into kdepimlibs and kdepim. For the above mentioned merging to be possible, it makes sense for both to be in the same git module. This poses extra difficulty to the svn2git script.

'''Email threads'''

* Mid-January thread on scm-interest: http://thread.gmane.org/gmane.comp.kde.devel.pim/26726
* Early March thread on kde-core-devel (Till email): http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=63970
* Early March thread on kde-core-devel (Till follow-up):
http://thread.gmane.org/gmane.comp.kde.devel.core/63915/focus=64069

'''Resolved Issues'''

* Branch maintenance workflow '''Resolution: http://thread.gmane.org/gmane.comp.kde.scm-interest/1310'''
** KDAB maintains several branches of legacy versions of KDE for enterprise customer deployments. [http://websvn.kde.org:80/branches/kdepim/enterprise/ Enterprise 3.5] [http://websvn.kde.org:80/branches/kdepim/enterprise4/ Enterprise 4 (based on KDE 4.2)]. The current KDEPIM trunk known as Enterprise 5 and is Akonadi based.
** Periodically (weekly or so), tags are created from the enterprise branches with bugfixes. http://websvn.kde.org:80/tags/kdepim/ Customers can download the tagged versions with the latest updates. Fixes are merged from the Enterprise 3.5 branch, and into trunk (which sometimes involves a lot of work, as the fix must be ported to Akonadi). Additionally, fixes get merged in the other direction. From official KDE modules into the Enterprise branches.
** Some fixes from Enterprise 3.5 should not be merged into Enterprise 4 for reasons such as no longer being reproducible. Some fixes do not get merged for a long time because they require so much work that porting the fix or feature is deffered. There needs to be a list of commits which should never be merged (blocked commits), and commits which should be merged, but have not been merged yet. The tool [[Development/Tools/svnmerge.py|svnmerge]] is used to facilitate this. svnmerge uses svn properties to maintain lists of commits that are blocked and that have already been integrated. See for example the svn-blocked and svn-integrated properties here: http://websvn.kde.org:80/trunk/KDE/kdepim/. The lists of commits available to be merged into the various branches are here: http://www.kdab.com/~thomas/avail/
** There needs to be a way in git to keep track of what commits have been merged, what commits need to be merged, and what commits are blocked. There needs to be a way of merging only specific commits from a branch, but not all, and not blocked commits. Proposed solutions:
*** git cherry-pick allows 'merging' of individual commits, but does not record where the commits came from. Instead it creates a new commit without any reference to where it came from. This alone is unsuitable.
*** branch per fix. This would lead to an explosion of branches which is not a problem in git as all commits are branches. It may make gitk un-navigatable. There would need to be a naming convention such as komo-merge-<fixname> for branches which should be merged. The commands <tt>git checkout 4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout enterprise4.5 && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt> and <tt>git checkout master && git merge $(git branch -a | grep -E ^origin/komo-merge)</tt>. That could of course be optimized, but gets the point across. If the code has changed so much that the branch is unmergable, but the fix still needs to be in trunk, the system breaks down.
*** Custom git command with flat text files representing the same information as svnmerge, that is lists of blocked and integrated commits. This is most likely to be a workable solution, possibly together with conventional branch naming.
* Internal Tools and external customer tools and workflows
** KDAB is a consumer of KDE software, but also has downstream customers fetching software from where it is developed. That is, KDE SVN. For example packages are created from the tags in tags/kdepim. Some of these downstreams are less close to KDE and depend on current workflows. If KDE SVN is not the place to get those updates anymore, this needs to be communicated to those downstreams, and the tools updated. ''Estimate'' 1 week to port the tools.
*** Internally used tools have been updated and are now being used to access git repos such as dbus.
* Other commitments
** Project deadlines and other commitments prevent the possibility of blocking off time to work on git migration when so many other things need to be done which have milestones separate to KDE cycles. The required work to convert to git can't be prioritized as highly, and so will take more time.
*** Most of the technical work regarding migration of kdepim repos has been completed by community member Torgny Nyblom.
* Tool knowledge
** People who don't currently know how to use git need to get familiar with it so that transitioning will be nearly seamless, and not result in too much development slowdown.
*** Workshops and use of git-svn have been used to bring developers up to speed on how to use git at some level.

=Nice to have before the migration=

==Push log==
{{Progress bar|100}}
'''Owner:''' sysadmin

'''Status:''' finished

It's a push log, similar to a local repository's reflog.

---------------

For every push, log:
- who pushed (not the Unix username, which will be "git")
- which branch heads changed (what from, what to)
- which tags were created
- the state of all other branches and tags

Just use git commit-tree with the empty tree and save everything in the commit
message, one after the other.

-----------

Gitolite includes this functionality inbuilt to itself, although all repositories are logged in the same file - bcooksley

==Script for downloading virtual KDE hierarchies==
{{Progress bar|99}}
'''Owner''':

'''Status:'''

:we already have kdesvn-build, build-tool and mr: three good tools for managing repos.

Most people use kdesrc-build; it will neither eat babies nor kittens. it has options for updating everything or individual modules, can do fetch-only or build-only, etc..
Command-line options for updating the configuration would be a nice addition.

TODO: details on mr and build-tool

note: scripty also has its own list of repos. it's just in a rather weird bash file.

'''Discussion:'''

As far as I can see, kdesvn-build is able to do it, it should be just a matter of providing a configuration. As I'm not using build-tool, I can't say anything about it. --jmho

'''Links'''
*[http://kdesvn-build.kde.org/ kdesvn-build]
*[[Projects/MovetoGit/MassCloneScript]]
*[http://rubyforge.org/projects/build-tool/ build-tool]
*TODO: link to mr

==pre-receive hooks==
{{Progress bar|50}}
'''Owner:''' ''volunteers needed!!''

* Line endings and encodings

'''Discussion:'''
this got accidentally marked as done or something, but it's not.

This has now been ported to Git - bcooksley

Note however that it doesn't look for a .gitattributes file yet - patches welcome ( see sysadmin/repo-management on git.kde.org )

'''Notes:'''
> > As for line-endings, be careful because Git is different from Subversion.
>
> different how?

Just ensure that all files are stored as LF only, except if there's a
.gitattributes file saying "-crlf" (i.e., allow it to have CRLF).

==Snapshot to read-only svn==
{{Progress bar|0}}
'''Owner:'''

:It's work, but maybe some people would like it. NEEDED for documentation, in order to get it back into SVN for the translators/scripty/?

'''Discussion'''

:Could be done with a git-svn gateway presumably? -Mike Arthur 19/10/2009 16:04

:if we leave the docbook stuff in svn, we can avoid this a bit longer. --[[User:Chani|Chani]] 23:21, 12 November 2009 (UTC)

==[[Development/Tutorials/Git|Techbase Documentation]]==
'''Owner:''' Chani, greeneg, - ''please help out!''
{{Progress bar|10}}

:At least minimal documentation about how to checkout, how to request a merge needed, other git documentation and links to other git information would be very useful also.

:see the [[Development/Tutorials/Git|Git Tutorial Page]]. help wanted!!

'''Discussion'''

==Setup git mirrors for cloning==
{{Progress bar|0}}
'''Owner:''' No one (help!)
:Re-purpose the anonsvn servers. This item might be a blocker.
'''Discussion'''

==Local pre-commit hooks==
{{Progress bar|0}}
'''Owner:''' argonel

:A set of recommended local hooks that give useful warnings could be nice to have.

'''Discussion'''
...on the other hand, if we get a lot of bikeshedding about what hooks, then it won't be so nice. so I'd put this in the "very optional" pile. --[[User:Chani|Chani]] 19:10, 16 December 2009 (UTC)

=Post-migration Issues=

==Website Branding==
{{Progress bar|2|text=(initial ideas on the table)}}
'''Owner:''' ruphy

:KDE Gitorious should be branded accordingly, and should be reachable from git.kde.org as well as kde.gitorious.org

'''Discussion'''

Is this section still necessary at all? Perhaps some branding has to be done for redmine or cgit, but I don't know. --jmho

=Unscheduled & Open=

==Allow tagging without involving sysadmins==
{{Progress bar|100}}

'''Owner:''' sysadmin

:Gitolite allows sysadmin to permit certain people on certain repos only to manage both branches and tag without needing force push rights.

'''Discussion'''

==Account setup for Gitolite==
{{Progress bar|0}}

'''Owner:''' ''sysadmin''

:Accounts for existing SVN accounts which use SSH for access have been automatically granted access to Gitolite. Those who are still using HTTPS need to file a sysadmin bug to change their SVN account to SSH and will recieve Git access automatically.

==post-update hooks==
{{Progress bar|90}}
'''Owner:''' ''morice'' ''Ian Monroe''

:* License checker

'''Discussion:'''
We have a fairly complete set of post-update hooks now. See [http://gitorious.org/remotehook remotehook]. However, it would be nice to have a system that lives on the Gitorious server and/or requires less manual maintenance. But its certainly workable and no longer a blocker.

=Completed Tasks=

==Get rid of svn:externals==
{{Progress bar|100}}
'''Owner:''' David Faure

'''Status:''' ''???''

:not possible with git, broken by design.

::

'''Discussion'''

Exists, but ignorable:
* kdesupport shared-desktop-ontologies (temporary)
* playground/utils strigi-chemical/test/ctfr
* playground/devtools kdevelop4-extra-plugins/php/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/python/parser/generated/kdevelop-pg-qt
* playground/devtools kdevelop4-extra-plugins/qmake/parser/generated/kdevelop-pg-qt
* playground/devtools kommander-plugins/database3/admin
* playground/devtools kommander-plugins/database/admin
* playground/devtools kommander-plugins/datetimefuncs/admin
* playground/devtools kommander-plugins/htmlpart/admin
* playground/devtools kommander-plugins/httpform/admin
* playground/devtools kommander-plugins/kparts/admin
* playground/devtools kommander-plugins/qtactionproxy/admin
* playground/devtools kommander-plugins/timewidget/admin
* playground/devtools kommander-plugins/webkit3/admin
* playground/devtools kpackagemaker/admin

==EBN==
{{Progress bar|95}}
'''Owner:''' ''drf''

'''Status:''' ''Amarok has EBN checks''

:EBN's krazy checks currently run on kde's svn repo; it needs upgrading to download and check our git repos too.

:This would be easier if there was a repo-list that EBN could parse, as it can no longer just svn up to get everything.

==Talk to people using other distros about git==
{{Progress bar|100}}
'''Owner:''' Sebas, Eike

'''Discussion'''
* Gentoo: They seem to be prepared for moving their live SVN packages to git; their package manager has easily-reusable classes to fetch from an SCM and moving the ebuilds to using the git class rather than the SVN class should be easy. Positive comments to that end from people in #gentoo-kde.
* Fedora: Some unhappyness about git because SVN allows them to remotely produce a diff between two SVN URLs (or two revisions of one and the same URL) without making a checkout first, while git requires making a clone. Kevin Kofler (IRC nick Kevin_Kofler, #fedora-kde) says this will make their packager work harder.
* Debian: Is indifferent about the SCM switch.

==Post Update hooks==
{{Progress bar|100}}
'''Owner:''' ''morice, johan, mattr

:List of scripts needed:
:* BUG/CCMAIL
:* email/CIA

:Gitorious needs to provide a way for hooks to be called; KDE needs to write said hooks.

'''Discussion'''

:There is a branch of gitorious called web-hooks http://gitorious.org/gitorious/mainline/commits/web-hooks --Panagiotis Papadopoulos 1 November 2009
:Same situation as commit emails. I can do it but it doesn't scale well and a Gitorious-supported solution would be nicer. --[[User:Eean|eean]] 16:07, 12 November 2009 (UTC)

==Reviewboard==
{{Progress bar|100}}
'''Owner:''' darktears

This should be easily done with Gitorious web interface and merge requests actually.

'''Discussion'''

:but reviewboard has features gitorious (right now) doesn't, like commenting on specific lines and not having to set up a merge request. --chani
::Also email notifications when someone reviews are needed --thomasz
:We're working on this for someone else right now, so pretty soon --johan-s
:I consider the latest changes to gitorious to finish this. If more reviewboard features are still needed, and git supports reviewboard, I think this is something we can look at doing post-conversion. --Ian Monroe

==Gitorious Needs a feature to disable merge request emails for certain repos==
{{Progress bar|100}}
'''Owner:''' [http://gitorious.org/gitorious Gitorious]

Have a sensible system for merge request emails. This is now in place - you can join groups, chose whether to have emails on a per repo basis, etc.

==SSH blocked in corporations and universities.==
{{Progress bar|100}}
'''Owner:''' ''Unknown''

:Some universities tend to block the SSH port. There should be a workaround to use SSH on some different port. github.com already runs a SSH server on port 443. But that assumes you are using a proxy. It has been found that this hasn't worked with a lot of people, especially those who have a direct connection to the internet ( so some transparent blocking by the ISP ). It would be great if (almost) every KDE developer were to be asked to check if other ports work before KDE made the switch. Otherwise there could be an automated email where the git patches could be sent, and appropriately patched to the right location too.

'''Discussion'''

:http://blog.gitorious.org/2009/10/20/stuck-behind-a-firewall/, and there's always been HTTP cloning (although the current impl. in Git is a bit on the slow side) --johan-s

==Talk to windows guys about git.==
{{Progress bar|100}}
'''Owner:''' aseigo

'''Discussion'''

They aren't huge fans of git, but are using it. They require a single mainline and can't cope with multiple branches. Otherwise, it's workable, even if it will take an adjustment period.

==pre-commit hooks==
{{Progress bar|100}}
'''Owner:''' ''(unknown)''

:acltest, docbook, EOL/UTF-8

:A web hook isn't good enough for these because they have to run and return whether to allow the push, for every single push to every KDE repo.

'''Discussion'''

:gitorious guys said they *might* be willing to allow a few scripts on their server for KDE as a special exception, iirc. --chani

:: Yes, at least for basic things, heavier things like doc building would probably have to be mirrored (goes for pre/post) --johan-s

:It turns out that acl and docbook might not be needed so long as web and docs/ stuff stays in svn.

:: Here's where to find the current scripts - http://websvn.kde.org/trunk/kde-common/svn/hooks/ --[[User:Argonel|Argonel]] 23:06, 11 November 2009 (UTC)

::So: this is actually done because it needs no longer to be done? (boud)

::Apparently, so; moving to complete. (aseigo)

= other notes =

==kde-common/accounts==

Someone said: KDE accounts file is no longer necessary---used for mapping svn ID -> email, but we have that now from Gitorious.
Answer from David Faure: I strongly disagree. We still need a KDE accounts file. This is very useful for finding people's email addresses, and having an overview on the number of active kde contributors; and if we keep it we can even have a kdepim resource again for filling an addressbook from it, for completion in kmail's composer (so you can write to any other kde contributor by just typing his/her name). It's also used for populating automatically the kde-cvs-announce mailing-list, for announcements. kde-common/accounts is our family tree (well, list), let's not get rid of it.

Here's my proposal for a kde-common/accounts replacement for the git era: We write a post-receive hook that looks at every commit and records all known email addresses for a given real name as well as the commit hash and date of when an address was last encountered. We can then present that data in the form of a file like kde-common/accounts, or write a web interface to query it (with nice links to the commits on Gitorious, etc.) --Eike (Sho_ on IRC)

To clear up possible confusion: The author information for a given commit is baked into the commit object itself, and comes from the configuration of the git repository it was created in. It is unrelated to any Gitorious account. Due to the distributed nature of Git, the one who uses his Gitorious account to push a commit need not be the same who created it. If Developer A creates a commit in his local clone and Developer B fetches it into his local clone directly from Developer A's machine and then pushes it into the public repo, the repo will only show a commit from Developer A. The Gitorious website will show that Developer B has pushed up a commit from Developer A, but that data is not contained in the repository. Thus collecting only Gitorious accounts and their mail addresses is insufficient. --Eike

==Random==
http://mail.kde.org/pipermail/dot-stories/2005-May/000509.html might be a good guide on what docs we need.

some of this stuff was from the list from GCDS that was in this email [http://markmail.org/message/u6eqfjece7fibfyo http://markmail.org/message/u6eqfjece7fibfyo]

==IRC Meetings==
* [[Projects/MovetoGit/Meeting1111|Minutes]] of meeting 11 November 2009
* [[Projects/MovetoGit/Meeting1118|Next meeting]] 18:00, 25 November 2009 (UTC)

= jobs =
''TODO merge this with the todolists above''

michael jansen: talking to kdesvn-build/mpyne
:--Done? -> http://kdesvn-build.kde.org/releases/kdesvn-build-1.10.php -- Panagiotis Papadopoulos 1 November 2009
::Yes, but the __kdesvn-build-remote used in the impl isn't pleasant for users already on git so it still needs more work for them. [[User:Mpyne|Mpyne]] 20:32, 11 November 2009 (UTC)

jonas: domain name

chani: techbase docs for scripty

sebas/lydia/leo: communication with teams! tell people! keeping track that
everything is being done.

Projects/MoveToGit/UsingSvn2Git

2010-10-23T12:23:05Z

Toma: /* Getting the tools */

This page documents how to go about getting a KDE module ready for the Great Git Migration of 2010.

=== Servers to use for all developers ===

KDE Sysadmin provides 3 servers which are fully setup for writing rules. You can find more information about that on: http://community.kde.org/Sysadmin/DeveloperAccessForRuleWriting.

All registered KDE developers have access to these machines. The rest of this document assumes a setup on your local computer, you are free to set it up on your local computer, but there is no need to. You can use the servers provided by KDE Sysadmin.

=== Getting the tools ===

The necessary tools are hosted at [http://www.gitorious.org/svn2git http://www.gitorious.org/svn2git]. To get started do:

<code bash>
git clone git://gitorious.org/svn2git/svn2git.git
git clone git://git.kde.org/kde-ruleset.git
</code>

And then install the libsvn-dev package.

This will get you the source code to build svn2git and the KDE ruleset files as they currently exist. Build the svn2git tool before moving on to the next step.

==== Building svn2git ====
Make sure you have Qt4 installed, then simply issue
<nowiki>qmake && make</nowiki> to build the executable called "svn-all-fast-export"

=== How rulesets work ===
The format for the svn2git rules is pretty simple. First and foremost you
have to declare some repositories:

<pre>
create repository kdelibs
end repository
</pre>

This tells svn2git that it should create a git repository called "kdelibs" that we can later on use to put commits into it.

The rest of the file are rules matching specific paths in Subversion, each rule
specifies what to do with the commits that appeared at the given path. The
possible actions are ignoring them or adding them to a particular branch in a particular repository. '''Note:''' Ignoring is done by simply leaving out the information about the repository and the branch.

As examples are more explanatory, the following rule would put all commits from 123453 to 456789 from the path /trunk/KDE/kdelibs into the master branch of
the kdelibs repository:
<pre>
match /trunk/KDE/kdelibs/
min revision 123453
max revision 456789
repository kdelibs
branch master
end match
</pre>

The min and max revision are useful in cases where the same path in SVN contains
code for different branches. An example would be KDevelop3, where KDevelop 3.3 was shipped with KDE 3.5 until 3.5.7, 3.5.8 contained KDevelop 3.4 and 3.5.9 contained KDevelop 3.5 and all of those kdevelop versions are now under /branches/KDE/3.5/kdevelop.

The two revision parameters are however not mandatory, if they're left out, then all commits that went to the given matching path in SVN are taken over into the specified branch.

To generate tags with git you use a special format for the branch parameter: refs/tags/<tagname>. So to put all commits from /tags/KDE/4.4.0/kdelibs into the v4.4.0 tag in the kdelibs git repository the rule would be like this:

<pre>
match /tags/KDE/4.4.0/kdelibs/
repository kdelibs
branch refs/tags/v4.4.0
end match
</pre>

For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.

The recurse action is a hack to tell svn2git to recurse into a directory it
has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <code bash>svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code>

SVN recorded in that commit that branches/KDE/4.4 was the only path changed.
That means the rule <pre>branches/KDE/[^/]+/kdelibs/</pre> will not match.

We need to tell the tool that something interesting happened inside and it
should recurse. Then it will apply again all rules to the files that exist at
that point, at which point the rules will match.

==== Important Details ====

* All matching rules need to end with a '/', else the tool will crash at some point. This is a known bug. The only exception are the rules using the recurse-action.

* Matching rules can use Regular Expressions (according to the QRegExp syntax) in the match line and can use backreferences in the repository and branch parameters using \n (n=1,2,3,...) to reduce the amount of rules.

* The rules form an ordered list that the tool goes through while matching the changed paths for each commit. So if two rules match the same path and neither of the two has more matching criteria, then the rule that is written further up in the file wins. This is useful to exclude certain commits from the extraction process, if you look at the existing kde ruleset you'll notice that at the top some revisions are ignored.

=== Setting up your system ===

You will need ~65GB of disk space to get started, as the process requires a copy of the KDE svn database. There is a script that will download this for you (and which can be used to update it periodically using rsync) in kde-ruleset/bin/startSync.

more stuff goes here ...

=== Step-by-Step on writing rules for a module ===

==== Analyzing Subversion history to write rules ====
First of all you should check wether there are already rules for this module in the kde-ruleset repository. If there are rules already please go down to "Running svn2git"

If there are no rules yet, lets start with the master (aka trunk) branch. The easiest way to find out history with svn is executing:
<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/trunk/KDE/module</pre>

Please note that '/path/to/kde_svn/' is the path to the 65GB you downloaded, and the 'trunk/KDE/module' is the module you want to write rules for, but those two put together is *not* a path that physically exists on your disk. svn log is smart enough to do what you want.

This will give you a history of the given module in trunk, it'll stop on the first commit that copied the code from somewhere else. The verbose output will allow you to see where this copy came from.

Now we have a starting point to write a rule, we want all commits from this path in our module repository in the master branch:
<pre>
match /trunk/KDE/module/
repository module
branch master
end match
</pre>
If the log stops at a commit that copied the module from somewhere, we need to
follow this to also get the history imported from the "old" place the module resided. The same svn command can be used with slightly different path argument:

<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/some/other/path@revision</pre>
The @revision is important as the original path usually doesn't exist anymore. With this we can write the next rule to the rules file and repeat until we've finally reached the point where the code was initially imported into svn (or probably cvs in the old days)

Now we can take care of the branches, this is a bit more involved as there may be multiple branches scattered over the /branches directory in svn. You can use the same commands as before to find out the history of a branch if you know the path. This time however you can stop following the source of copy-operations once you've found a source that you've already matched in a rule. That way your branch will be connected to the branch it originated from (which is often trunk aka master) in git.

A useful help with finding branches is svn ls in combination with the path@revision syntax, that way you can view the content of a particular svn directory as it was in an older revision. With this you can even find branches that are not visible (have been deleted) in the current revision.

The rule for putting commits into a git branch in the final repository is only slightly different (the example is for a core module):
<pre>
match /branches/KDE/4.4/module
repository module
branch 4.4
end match
</pre>

And last are the tags, this works the same as branches and trunk, except for using branch refs/tags/v<tag-version> for the branch parameter.

==== Running svn2git ====
This is the easiest, but most time-consuming part. As example lets say that in our current working directory we have the kde rules repository in kde-ruleset subdir, the svn2git tool in the svn2git subdir and the KDE repository in the kde_svn subdir:
<pre>
svn2git/svn-all-fast-export --identity-map kde-ruleset/account-map --rules kde-ruleset/module kde_svn
</pre>

This will take a few hours usually, but it'll spit out the progress. The tool also writes a logfile to module.log, so in case something goes wrong you can find more details in there.

Once its done you should have a new "module" git repository in your current working directory.

==== Checking for proper history in the new git repository ====
A very easy way to check wether the history was imported properly is to use the gitk tool from git. It shows you a graphical representation of the history in the git repository which makes it easy to identify where something is wrong.

The tool should be run with the --all switch so it shows all branches.

You can now scroll through the history to check wether things have been imported correctly.

First and foremost there should be the master branch starting at the top with the most recent commit to trunk/ and ending in the oldest commit that imported the code into KDE's svn or cvs repository.

From the master branch there should be several branches going away for each branch you imported. And eventually also branches that start from another non-master branch.

Things that you should look out for are branches that start "nowhere", that is the first commit in the branch has no parent in another branch or master. This means that svn2git didn't see a commit that created this branch from another using a svn cp command. That can mean that you may have forgotton to add a match rule for some path or that the same path was used for different branches in different revisions. The same applies to tags which have a commit without any parent.

This can usually be fixed by using svn log and svn ls to follow the history of the branch. Eventually you might need to apply the min/max revision paramters.

You'll notice that some tags are looking like this:

<pre>
|
* * <v1.2.3>
| |
* *
| /
*
</pre>

Thats normal for our tags even if a bit ugly. The reason is that often compile-fixes are done in trunk/ after the tag has been created and then the commit has been merged over to the tag.

Another thing however are tags that are named vx.y.z_124321. These are tags that have been deleted and re-created later. You can usually see that in the svn log history, these tags can either be manually deleted after the repository creation using git tag or you can add rules that ignore certain revisions of the tag-path before the one putting the commits into the git repository:

<pre>
match /tags/KDE/3.3.2/kdelibs
min revision 424234
max revision 424236
end match
match /tags/KDE/3.3.2/kdelibs
repository kdelibs
branch refs/tags/3.3.2
end match
</pre>

If you choose to delete them manually please make sure to document this with a textfile or inside the rule file so if someone else does the conversion later again he'll know what manual steps you did.

Before publishing the newly created git repository make sure to repack it. This can greatly reduce it's size (i.e. Phonon's git repository could be shrunken from 18 MB to 5.2 MB)

==== How to update the account-map file ====

Currently, account-map file is being generated with 'generateAccountMap'[http://gitorious.org/svn2git/kde-ruleset/blobs/master/bin/generateAccountMap] script which parses kde-common/accounts[http://websvn.kde.org/trunk/kde-common/accounts?view=log] and kde-common/disabled-accounts[http://websvn.kde.org/trunk/kde-common/disabled-accounts?view=log] from SVN.

Once you have your git repository you should check if there are accounts not listed in account-map file (you can use checkMissingAccounts[http://gitorious.org/svn2git/kde-ruleset/blobs/master/bin/checkMissingAccounts]), if that is the case, check if the missing accounts are listed in kde-common/accounts or kde-common/disabled-accounts, if it's not there file a sysadmin bug report[https://bugs.kde.org/enter_sysadmin_request.cgi] to get your missing account included in disabled-accounts. Once you get your missing accounts included in disabled accounts, you could generate the account-map file running 'bin/generateAccountMap', then run svn-all-fast-export again. Do not edit account-map file directly!

=== Troubleshooting ===

==== Recurse action doesn't work with cvs2svn tag commits ====

You may have to deal with a commit done by cvs2svn to create a tag, for example:
<pre>
r386536 | (no author) | 2005-02-05 22:16:00 +0100 (Sat, 05 Feb 2005) | 2 lines
Changed paths:
A /branches/beta_0_7_branch (from /trunk:386535)
D /branches/beta_0_7_branch/art-devel
D /branches/beta_0_7_branch/arts
D /branches/beta_0_7_branch/bugs
D /branches/beta_0_7_branch/devel-home
D /branches/beta_0_7_branch/developer.kde.org
D /branches/beta_0_7_branch/enterprise.kde.org
D /branches/beta_0_7_branch/events.kde.org
D /branches/beta_0_7_branch/foundation
D /branches/beta_0_7_branch/kckde
D /branches/beta_0_7_branch/kde-common
D /branches/beta_0_7_branch/kde-i18n
D /branches/beta_0_7_branch/kde-qt-addon
D /branches/beta_0_7_branch/kde-women.kde.org
D /branches/beta_0_7_branch/kdeaccessibility
D /branches/beta_0_7_branch/kdeaddons
D /branches/beta_0_7_branch/kdeadmin
D /branches/beta_0_7_branch/kdeartwork
D /branches/beta_0_7_branch/kdebase
D /branches/beta_0_7_branch/kdebindings
D /branches/beta_0_7_branch/kdeedu
D /branches/beta_0_7_branch/kdeextragear-1
D /branches/beta_0_7_branch/kdeextragear-2
M /branches/beta_0_7_branch/kdeextragear-3
D /branches/beta_0_7_branch/kdeextragear-3/Makefile.am.in
D /branches/beta_0_7_branch/kdeextragear-3/Makefile.cvs
D /branches/beta_0_7_branch/kdeextragear-3/README
D /branches/beta_0_7_branch/kdeextragear-3/configure.in.bot
D /branches/beta_0_7_branch/kdeextragear-3/configure.in.in
D /branches/beta_0_7_branch/kdeextragear-3/digikam
D /branches/beta_0_7_branch/kdeextragear-3/digikamimageplugins
D /branches/beta_0_7_branch/kdeextragear-3/doc
D /branches/beta_0_7_branch/kdeextragear-3/filelight
D /branches/beta_0_7_branch/kdeextragear-3/kcfgcreator
D /branches/beta_0_7_branch/kdeextragear-3/kconfigeditor
D /branches/beta_0_7_branch/kdeextragear-3/kdebluetooth
D /branches/beta_0_7_branch/kdeextragear-3/kdetv
D /branches/beta_0_7_branch/kdeextragear-3/keurocalc
D /branches/beta_0_7_branch/kdeextragear-3/kiosktool
D /branches/beta_0_7_branch/kdeextragear-3/klicker
D /branches/beta_0_7_branch/kdeextragear-3/kplayer
D /branches/beta_0_7_branch/kdeextragear-3/pwmanager
D /branches/beta_0_7_branch/kdeextragear-libs-1
D /branches/beta_0_7_branch/kdegames
D /branches/beta_0_7_branch/kdegraphics
D /branches/beta_0_7_branch/kdeinstaller
D /branches/beta_0_7_branch/kdejava
D /branches/beta_0_7_branch/kdekiosk
D /branches/beta_0_7_branch/kdelibs
D /branches/beta_0_7_branch/kdemultimedia
D /branches/beta_0_7_branch/kdenetwork
D /branches/beta_0_7_branch/kdenonbeta
D /branches/beta_0_7_branch/kdenox
D /branches/beta_0_7_branch/kdepim
D /branches/beta_0_7_branch/kdeplayground-artwork
D /branches/beta_0_7_branch/kdeplayground-base
D /branches/beta_0_7_branch/kdeplayground-edu
D /branches/beta_0_7_branch/kdeplayground-games
D /branches/beta_0_7_branch/kdeplayground-ioslaves
D /branches/beta_0_7_branch/kdeplayground-multimedia
D /branches/beta_0_7_branch/kdeplayground-network
D /branches/beta_0_7_branch/kdeplayground-pim
D /branches/beta_0_7_branch/kdeplayground-utils
D /branches/beta_0_7_branch/kdereview
D /branches/beta_0_7_branch/kdesdk
D /branches/beta_0_7_branch/kdesecurity
D /branches/beta_0_7_branch/kdesupport
D /branches/beta_0_7_branch/kdetoys
D /branches/beta_0_7_branch/kdeutils
D /branches/beta_0_7_branch/kdevelop
D /branches/beta_0_7_branch/kdewebdev
D /branches/beta_0_7_branch/kdoc
D /branches/beta_0_7_branch/kfte
D /branches/beta_0_7_branch/khtmltests
D /branches/beta_0_7_branch/klyx
D /branches/beta_0_7_branch/kmusic
D /branches/beta_0_7_branch/koffice
D /branches/beta_0_7_branch/kofficetests
D /branches/beta_0_7_branch/konstruct
D /branches/beta_0_7_branch/qt-copy
D /branches/beta_0_7_branch/quanta
D /branches/beta_0_7_branch/sysconfig
D /branches/beta_0_7_branch/valgrind
D /branches/beta_0_7_branch/www

This commit was manufactured by cvs2svn to create branch
'beta_0_7_branch'.
</pre>
If you do this
<pre>
match /branches/beta_0_7_branch/kdeextragear-3/krecipes/
repository krecipes
branch 0.7
end match

match /branches/beta_0_7_branch/
min revision 386536
max revision 386536
action recurse
end match
</pre>
svn-all-fast-export will fail, you'll get an error sayining that '/foo/bar/path' was not found where '/foo/bar/path' is one of the deleted paths in the cvs2svn commit. This is because some paths were deleted in the same commit where you want to do an 'action recurse'. Therefore, to avoid matching the deleted paths you should do an action recurse on each intermediate directory from '/branches/beta_0_7_branch/' to '/branches/beta_0_7_branch/kdeextragear-3/krecipes/' and you should use a final '$' to make sure that the deleted paths will not be considered, thusly:
<pre>
match /branches/beta_0_7_branch/kdeextragear-3/krecipes/
repository krecipes
branch 0.7
end match

match /branches/beta_0_7_branch/kdeextragear-3/$
min revision 386536
max revision 386536
action recurse
end match

match /branches/beta_0_7_branch/$
min revision 386536
max revision 386536
action recurse
end match
</pre>

=== Getting Help ===
If you run into strange things or can't find a rule for something you can reach the KDE Git migration team on IRC: irc.freenode.org, #kde-git or on the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest mailinglist]

Projects/MoveToGit/UsingSvn2Git

2010-10-05T20:53:09Z

Toma: /* Analyzing Subversion history to write rules */

This page documents how to go about getting a KDE module ready for the Great Git Migration of 2010.

=== Getting the tools ===

The necessary tools are hosted at [http://www.gitorious.org/svn2git http://www.gitorious.org/svn2git]. To get started do:

<code bash>
git clone git://gitorious.org/svn2git/svn2git.git
git clone git://gitorious.org/svn2git/kde-ruleset.git
</code>

And then install the libsvn-dev package.

This will get you the source code to build svn2git and the KDE ruleset files as they currently exist. Build the svn2git tool before moving on to the next step.

==== Building svn2git ====
Make sure you have Qt4 installed, then simply issue
<nowiki>qmake && make</nowiki> to build the executable called "svn-all-fast-export"

=== How rulesets work ===
The format for the svn2git rules is pretty simple. First and foremost you
have to declare some repositories:

<pre>
create repository kdelibs
end repository
</pre>

This tells svn2git that it should create a git repository called "kdelibs" that we can later on use to put commits into it.

The rest of the file are rules matching specific paths in Subversion, each rule
specifies what to do with the commits that appeared at the given path. The
possible actions are ignoring them or adding them to a particular branch in a particular repository. '''Note:''' Ignoring is done by simply leaving out the information about the repository and the branch.

As examples are more explanatory, the following rule would put all commits from 123453 to 456789 from the path /trunk/KDE/kdelibs into the master branch of
the kdelibs repository:
<pre>
match /trunk/KDE/kdelibs/
min revision 123453
max revision 456789
repository kdelibs
branch master
end match
</pre>

The min and max revision are useful in cases where the same path in SVN contains
code for different branches. An example would be KDevelop3, where KDevelop 3.3 was shipped with KDE 3.5 until 3.5.7, 3.5.8 contained KDevelop 3.4 and 3.5.9 contained KDevelop 3.5 and all of those kdevelop versions are now under /branches/KDE/3.5/kdevelop.

The two revision parameters are however not mandatory, if they're left out, then all commits that went to the given matching path in SVN are taken over into the specified branch.

To generate tags with git you use a special format for the branch parameter: refs/tags/<tagname>. So to put all commits from /tags/KDE/4.4.0/kdelibs into the v4.4.0 tag in the kdelibs git repository the rule would be like this:

<pre>
match /tags/KDE/4.4.0/kdelibs/
repository kdelibs
branch refs/tags/v4.4.0
end match
</pre>

For more examples see the svn2git/samples/ directory and the rules in the kde-ruleset repository.

The recurse action is a hack to tell svn2git to recurse into a directory it
has just copied or that existed because it is of interest. Example: if we are importing kdelibs, it exists in {{path|trunk/KDE/kdelibs}}. At branching, someone did: <code bash>svn cp $SVNROOT/trunk/KDE $SVNROOT/branches/KDE/4.4</code>

SVN recorded in that commit that branches/KDE/4.4 was the only path changed.
That means the rule <pre>branches/KDE/[^/]+/kdelibs/</pre> will not match.

We need to tell the tool that something interesting happened inside and it
should recurse. Then it will apply again all rules to the files that exist at
that point, at which point the rules will match.

==== Important Details ====

* All matching rules need to end with a '/', else the tool will crash at some point. This is a known bug. The only exception are the rules using the recurse-action.

* Matching rules can use Regular Expressions (according to the QRegExp syntax) in the match line and can use backreferences in the repository and branch parameters using \n (n=1,2,3,...) to reduce the amount of rules.

* The rules form an ordered list that the tool goes through while matching the changed paths for each commit. So if two rules match the same path and neither of the two has more matching criteria, then the rule that is written further up in the file wins. This is useful to exclude certain commits from the extraction process, if you look at the existing kde ruleset you'll notice that at the top some revisions are ignored.

=== Setting up your system ===

You will need ~65GB of disk space to get started, as the process requires a copy of the KDE svn database. There is a script that will download this for you (and which can be used to update it periodically using rsync) in kde-ruleset/bin/startSync.

more stuff goes here ...

=== Step-by-Step on writing rules for a module ===

==== Analyzing Subversion history to write rules ====
First of all you should check wether there are already rules for this module in the kde-ruleset repository. If there are rules already please go down to "Running svn2git"

If there are no rules yet, lets start with the master (aka trunk) branch. The easiest way to find out history with svn is executing:
<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/trunk/KDE/module</pre>

Please note that '/path/to/kde_svn/' is the path to the 65GB you downloaded, and the 'trunk/KDE/module' is the module you want to write rules for, but those two put together is *not* a path that physically exists on your disk. svn log is smart enough to do what you want.

This will give you a history of the given module in trunk, it'll stop on the first commit that copied the code from somewhere else. The verbose output will allow you to see where this copy came from.

Now we have a starting point to write a rule, we want all commits from this path in our module repository in the master branch:
<pre>
match /trunk/KDE/module/
repository module
branch master
end match
</pre>
If the log stops at a commit that copied the module from somewhere, we need to
follow this to also get the history imported from the "old" place the module resided. The same svn command can be used with slightly different path argument:

<pre>svn log -v --stop-on-copy file:///path/to/kde_svn/some/other/path@revision</pre>
The @revision is important as the original path usually doesn't exist anymore. With this we can write the next rule to the rules file and repeat until we've finally reached the point where the code was initially imported into svn (or probably cvs in the old days)

Now we can take care of the branches, this is a bit more involved as there may be multiple branches scattered over the /branches directory in svn. You can use the same commands as before to find out the history of a branch if you know the path. This time however you can stop following the source of copy-operations once you've found a source that you've already matched in a rule. That way your branch will be connected to the branch it originated from (which is often trunk aka master) in git.

A useful help with finding branches is svn ls in combination with the path@revision syntax, that way you can view the content of a particular svn directory as it was in an older revision. With this you can even find branches that are not visible (have been deleted) in the current revision.

The rule for putting commits into a git branch in the final repository is only slightly different (the example is for a core module):
<pre>
match /branches/KDE/4.4/module
repository module
branch 4.4
end match
</pre>

And last are the tags, this works the same as branches and trunk, except for using branch refs/tags/v<tag-version> for the branch parameter.

==== Running svn2git ====
This is the easiest, but most time-consuming part. As example lets say that in our current working directory we have the kde rules repository in kde-ruleset subdir, the svn2git tool in the svn2git subdir and the KDE repository in the kde_svn subdir:
<pre>
svn2git/svn-all-fast-export --identity-map kde-ruleset/account-map --rules kde-ruleset/module kde_svn
</pre>

This will take a few hours usually, but it'll spit out the progress. The tool also writes a logfile to module.log, so in case something goes wrong you can find more details in there.

Once its done you should have a new "module" git repository in your current working directory.

==== Checking for proper history in the new git repository ====
A very easy way to check wether the history was imported properly is to use the gitk tool from git. It shows you a graphical representation of the history in the git repository which makes it easy to identify where something is wrong.

The tool should be run with the --all switch so it shows all branches.

You can now scroll through the history to check wether things have been imported correctly.

First and foremost there should be the master branch starting at the top with the most recent commit to trunk/ and ending in the oldest commit that imported the code into KDE's svn or cvs repository.

From the master branch there should be several branches going away for each branch you imported. And eventually also branches that start from another non-master branch.

Things that you should look out for are branches that start "nowhere", that is the first commit in the branch has no parent in another branch or master. This means that svn2git didn't see a commit that created this branch from another using a svn cp command. That can mean that you may have forgotton to add a match rule for some path or that the same path was used for different branches in different revisions. The same applies to tags which have a commit without any parent.

This can usually be fixed by using svn log and svn ls to follow the history of the branch. Eventually you might need to apply the min/max revision paramters.

You'll notice that some tags are looking like this:

<pre>
|
* * <v1.2.3>
| |
* *
| /
*
</pre>

Thats normal for our tags even if a bit ugly. The reason is that often compile-fixes are done in trunk/ after the tag has been created and then the commit has been merged over to the tag.

Another thing however are tags that are named vx.y.z_124321. These are tags that have been deleted and re-created later. You can usually see that in the svn log history, these tags can either be manually deleted after the repository creation using git tag or you can add rules that ignore certain revisions of the tag-path before the one putting the commits into the git repository:

<pre>
match /tags/KDE/3.3.2/kdelibs
min revision 424234
max revision 424236
end match
match /tags/KDE/3.3.2/kdelibs
repository kdelibs
branch refs/tags/3.3.2
end match
</pre>

If you choose to delete them manually please make sure to document this with a textfile or inside the rule file so if someone else does the conversion later again he'll know what manual steps you did.

Before publishing the newly created git repository make sure to repack it. This can greatly reduce it's size (i.e. Phonon's git repository could be shrunken from 18 MB to 5.2 MB)

==== How to update the account-map file ====

Currently, account-map file is being generated with 'generateAccountMap'[http://gitorious.org/svn2git/kde-ruleset/blobs/master/bin/generateAccountMap] script which parses kde-common/accounts[http://websvn.kde.org/trunk/kde-common/accounts?view=log] and kde-common/disabled-accounts[http://websvn.kde.org/trunk/kde-common/disabled-accounts?view=log] from SVN.

Once you have your git repository you should check if there are accounts not listed in account-map file (you can use checkMissingAccounts[http://gitorious.org/svn2git/kde-ruleset/blobs/master/bin/checkMissingAccounts]), if that is the case, check if the missing accounts are listed in kde-common/accounts or kde-common/disabled-accounts, if it's not there file a sysadmin bug report[https://bugs.kde.org/enter_sysadmin_request.cgi] to get your missing account included in disabled-accounts. Once you get your missing accounts included in disabled accounts, you could generate the account-map file running 'bin/generateAccountMap', then run svn-all-fast-export again. Do not edit account-map file directly!

=== Troubleshooting ===

==== Recurse action doesn't work with cvs2svn tag commits ====

You may have to deal with a commit done by cvs2svn to create a tag, for example:
<pre>
r386536 | (no author) | 2005-02-05 22:16:00 +0100 (Sat, 05 Feb 2005) | 2 lines
Changed paths:
A /branches/beta_0_7_branch (from /trunk:386535)
D /branches/beta_0_7_branch/art-devel
D /branches/beta_0_7_branch/arts
D /branches/beta_0_7_branch/bugs
D /branches/beta_0_7_branch/devel-home
D /branches/beta_0_7_branch/developer.kde.org
D /branches/beta_0_7_branch/enterprise.kde.org
D /branches/beta_0_7_branch/events.kde.org
D /branches/beta_0_7_branch/foundation
D /branches/beta_0_7_branch/kckde
D /branches/beta_0_7_branch/kde-common
D /branches/beta_0_7_branch/kde-i18n
D /branches/beta_0_7_branch/kde-qt-addon
D /branches/beta_0_7_branch/kde-women.kde.org
D /branches/beta_0_7_branch/kdeaccessibility
D /branches/beta_0_7_branch/kdeaddons
D /branches/beta_0_7_branch/kdeadmin
D /branches/beta_0_7_branch/kdeartwork
D /branches/beta_0_7_branch/kdebase
D /branches/beta_0_7_branch/kdebindings
D /branches/beta_0_7_branch/kdeedu
D /branches/beta_0_7_branch/kdeextragear-1
D /branches/beta_0_7_branch/kdeextragear-2
M /branches/beta_0_7_branch/kdeextragear-3
D /branches/beta_0_7_branch/kdeextragear-3/Makefile.am.in
D /branches/beta_0_7_branch/kdeextragear-3/Makefile.cvs
D /branches/beta_0_7_branch/kdeextragear-3/README
D /branches/beta_0_7_branch/kdeextragear-3/configure.in.bot
D /branches/beta_0_7_branch/kdeextragear-3/configure.in.in
D /branches/beta_0_7_branch/kdeextragear-3/digikam
D /branches/beta_0_7_branch/kdeextragear-3/digikamimageplugins
D /branches/beta_0_7_branch/kdeextragear-3/doc
D /branches/beta_0_7_branch/kdeextragear-3/filelight
D /branches/beta_0_7_branch/kdeextragear-3/kcfgcreator
D /branches/beta_0_7_branch/kdeextragear-3/kconfigeditor
D /branches/beta_0_7_branch/kdeextragear-3/kdebluetooth
D /branches/beta_0_7_branch/kdeextragear-3/kdetv
D /branches/beta_0_7_branch/kdeextragear-3/keurocalc
D /branches/beta_0_7_branch/kdeextragear-3/kiosktool
D /branches/beta_0_7_branch/kdeextragear-3/klicker
D /branches/beta_0_7_branch/kdeextragear-3/kplayer
D /branches/beta_0_7_branch/kdeextragear-3/pwmanager
D /branches/beta_0_7_branch/kdeextragear-libs-1
D /branches/beta_0_7_branch/kdegames
D /branches/beta_0_7_branch/kdegraphics
D /branches/beta_0_7_branch/kdeinstaller
D /branches/beta_0_7_branch/kdejava
D /branches/beta_0_7_branch/kdekiosk
D /branches/beta_0_7_branch/kdelibs
D /branches/beta_0_7_branch/kdemultimedia
D /branches/beta_0_7_branch/kdenetwork
D /branches/beta_0_7_branch/kdenonbeta
D /branches/beta_0_7_branch/kdenox
D /branches/beta_0_7_branch/kdepim
D /branches/beta_0_7_branch/kdeplayground-artwork
D /branches/beta_0_7_branch/kdeplayground-base
D /branches/beta_0_7_branch/kdeplayground-edu
D /branches/beta_0_7_branch/kdeplayground-games
D /branches/beta_0_7_branch/kdeplayground-ioslaves
D /branches/beta_0_7_branch/kdeplayground-multimedia
D /branches/beta_0_7_branch/kdeplayground-network
D /branches/beta_0_7_branch/kdeplayground-pim
D /branches/beta_0_7_branch/kdeplayground-utils
D /branches/beta_0_7_branch/kdereview
D /branches/beta_0_7_branch/kdesdk
D /branches/beta_0_7_branch/kdesecurity
D /branches/beta_0_7_branch/kdesupport
D /branches/beta_0_7_branch/kdetoys
D /branches/beta_0_7_branch/kdeutils
D /branches/beta_0_7_branch/kdevelop
D /branches/beta_0_7_branch/kdewebdev
D /branches/beta_0_7_branch/kdoc
D /branches/beta_0_7_branch/kfte
D /branches/beta_0_7_branch/khtmltests
D /branches/beta_0_7_branch/klyx
D /branches/beta_0_7_branch/kmusic
D /branches/beta_0_7_branch/koffice
D /branches/beta_0_7_branch/kofficetests
D /branches/beta_0_7_branch/konstruct
D /branches/beta_0_7_branch/qt-copy
D /branches/beta_0_7_branch/quanta
D /branches/beta_0_7_branch/sysconfig
D /branches/beta_0_7_branch/valgrind
D /branches/beta_0_7_branch/www

This commit was manufactured by cvs2svn to create branch
'beta_0_7_branch'.
</pre>
If you do this
<pre>
match /branches/beta_0_7_branch/kdeextragear-3/krecipes/
repository krecipes
branch 0.7
end match

match /branches/beta_0_7_branch/
min revision 386536
max revision 386536
action recurse
end match
</pre>
svn-all-fast-export will fail, you'll get an error sayining that '/foo/bar/path' was not found where '/foo/bar/path' is one of the deleted paths in the cvs2svn commit. This is because some paths were deleted in the same commit where you want to do an 'action recurse'. Therefore, to avoid matching the deleted paths you should do an action recurse on each intermediate directory from '/branches/beta_0_7_branch/' to '/branches/beta_0_7_branch/kdeextragear-3/krecipes/' and you should use a final '$' to make sure that the deleted paths will not be considered, thusly:
<pre>
match /branches/beta_0_7_branch/kdeextragear-3/krecipes/
repository krecipes
branch 0.7
end match

match /branches/beta_0_7_branch/kdeextragear-3/$
min revision 386536
max revision 386536
action recurse
end match

match /branches/beta_0_7_branch/$
min revision 386536
max revision 386536
action recurse
end match
</pre>

=== Getting Help ===
If you run into strange things or can't find a rule for something you can reach the KDE Git migration team on IRC: irc.freenode.org, #kde-git or on the [https://mail.kde.org/mailman/listinfo/kde-scm-interest kde-scm-interest mailinglist]

Contribute/Get a Contributor Account

2010-09-09T16:22:36Z

Toma: /* Updating Existing Account */

{{Template:I18n/Language Navigation Bar|Contribute/Get a SVN Account}}
This tutorial is about how to apply for a SVN account for KDE.

== Notations ==

* The word ''SVN'' applies to all SVN servers.
* The phrase ''KDE SVN'' refers only to KDE's SVN server.
* The phrase ''anonymous SVN'' means KDE's anonymous SVN mirrors.

== What is KDE SVN? ==

To have write access to KDE SVN, you have to use the main SVN server of KDE. (Anonymous SVN uses mirrors of this server. SVN does not allow you to read from one server and write to another.)

To be able to use the main KDE SVN server, you need an account there. An account is made up of a ''username'' (normally your family name), a password and an email address. The username is for getting in, the password for authenticating and the email address for knowing who to contact if another developer wants to contact the account holder. (The username is sometimes known also as the ''login''.)

A KDE SVN account allows you to write to nearly anywhere in the KDE SVN. However, there are exceptions:
* the KDE SVN internals
* the www module (exceptions can be made for this.)

'''Note''': you can see the accounts in [http://websvn.kde.org/trunk/kde-common/accounts kde-common/accounts]. That is the list of all accounts. Yes, '''the account list is public''', for example on [http://websvn.kde.org WebSVN].

== Who Can Apply For a KDE SVN Account? ==

Normally, any developer who has done some work on KDE can apply for a KDE SVN account.

Translators should get approval from their team leader so that they can organize how the work is being done in his/her team. Please mention the approval from the team leader when requesting the account.

Please also [[Policies/SVN Commit Policy|read the KDE SVN commit policy]]. You must accept these rules when using your future KDE SVN account. Please also familiarize yourself with the [http://www.kde.org/code-of-conduct/ KDE Code of Conduct] which describes the social foundations within KDE.

Also please apply for an account only if you think that you will work on KDE for a somewhat longer time. If you know that you will only work for a couple of weeks and then never again, please consider not applying for a KDE SVN account but still, do continue to send patches.

The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.

Of course, to be clear: ''the KDE's sysadmins have the last word about whether or not to create a KDE SVN account for somebody''.

== SSH ==

You need a SSH public key in order to access your KDE SVN account. If you already have one, you can skip the next subsection and go to [[#Setting up the SVN+SSH protocol|Setting up the SVN+SSH protocol]].

=== Generating the SSH keys ===

To be able to use your KDE SVN account with SSH, you need a SSH public key. Please notice that it is '''not''' a GPG (OpenPGP) key, which is completely unrelated!

The password in the sense of this documentation is the '''public key''' that you are creating.

For more information on how to create a pair o SSH keys, please refer to a [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen SSH documentation] or book.

In short, the command to create a pair of keys is '''ssh-keygen''' and it requires the type of key you will create, either DSA or RSA - both are fine.

To create a new pair of keys, use <code bash>ssh-keygen -t dsa</code> or <code bash>ssh-keygen -t rsa</code>

There is also a type called RSA1 which was used in version 1 of the SSH protocol. See the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen ssh documentation] for more details.

You can then accept the default filename for your key (either {{path|$HOME/.ssh/id_dsa}} or {{path|$HOME/.ssh/id_rsa}}, depending on the type of key you have chosen). After that, a passphrase is asked. It is recommended that you do not leave it blank.

Now that you are finished generating your key pair, you will have two files: a private key and a public key. If you have accepted the default filename, they will be respectively {{path|$HOME/.ssh/id_dsa}} and {{path|$HOME/.ssh/id_dsa.pub}} or {{path|$HOME/.ssh/id_rsa}} and {{path|$HOME/.ssh/id_rsa.pub}}, depending on the type of key you have specified.

The private key '''must''' remain secret, do not publish it to anyone under any circumstance.

The public key can be published and shall be sent when you are applying for a KDE SVN account.

You should also set up <tt>ssh-agent</tt> so you do not have to type the password every time you connect via SSH. There are several tutorials available explaining how to do this, for example [http://mah.everybody.org/docs/ssh this one]. [http://www.gentoo.org/proj/en/keychain Keychain] is a program that makes this task easier.

'''Note''': if you already have an ssh key, you can just use the existing key instead of creating a new one.

{{tip|
If you want to use SVN with SSH with another user than the one who created the keys, you need to copy <tt>$HOME/.ssh/id_dsa.pub</tt> and <tt>$HOME/.ssh/id_dsa</tt> or <tt>$HOME/.ssh/id_rsa.pub</tt> and <tt>$HOME/.ssh/id_rsa</tt> to the other user's <tt>$HOME/.ssh</tt> directory.

You should probably also backup those files.
}}

=== Setting up the SVN+SSH protocol ===

Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE sites. Add the following lines to the <tt>~/.ssh/config</tt> file. Replace USERNAME with yours.

<pre>
Host *.kde.org
User USERNAME
IdentityFile ~/.ssh/id_dsa
</pre>

The linked IdentityFile must belong to the public key you send in when applying for the SVN account. But it is ''not'' the public key (<tt>*.pub</tt>).

== Apply for an account ==

Now you are ready to apply for for a KDE SVN account. Go to [https://identity.kde.org/ https://identity.kde.org/svnaccount/] and create an account if you don't have one already. If you already have an account, you can use that. After you entered the site you will find a form which you can fill in to apply for an account.

When you register on identity.kde.org, you will need to enter your name and an e-mail address, which has to be your own (a normal address or a KDE Mail address). Of course, do not forget that '''this email address becomes public''' (at least by [http://websvn.kde.org WebSVN]) so you will unfortunately get spam.

Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have an account in [http://bugs.kde.org bugs.kde.org], please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address of your Subversion and [http://bugs.kde.org bugs.kde.org] accounts match.

After that, you must choose a username for your KDE SVN account between the suggestions presented to you. Please notice it is not possible to propose something else such as a nickname, as the username must be as close as possible to someone's real name.

If you ask for a KDE email address one day, this will be the base for your address. For example: <tt>username@kde.org</tt>. (Note, however, that KDE email addresses are not granted so easily anymore, as too many people have ranted with a KDE address and other people thought that it was the official position of the KDE Team. In the meantime, [http://www.kdemail.net KDE Mail] was created for if you need a permanent address.)

When applying for developer access you have to provide your public key. This key will be added to your profile. You can always add more keys, delete keys you don't use anymore from your profile page on identity.kde.org.

The form also holds a field ''Why do you want an account?'', where you can explain what you want to do with your future KDE SVN account, like for example developing a certain application, making documentations or being the team leader of a translation.

Also note that the form will ask you who has encouraged you to apply. He or she will also get an email to verify your request.

== Updating Existing Account ==

If you already have a KDE SVN account but want to update the ssh key, you should go to [https://identity.kde.org/ identity.kde.org] and change the keys in your profile.

== And Now? ==

After having sent the form and clicking the link in the email, you have to wait for the answer (typically within two or three days).

Once you have confirmation that your account has been created, you need to adapt your local copy to the new server. See the [[Contribute/First Steps with your KDE SVN Account|next tutorial]] for your first steps with your new account.

Please add your geographical location (what country are you in?) and other details at the [http://commit-digest.org/data/ Commit Digest data page] so that the Commit Digest can accurately reflect who is working where.

Contribute/Get a Contributor Account

2010-09-09T16:20:21Z

Toma: Change in the way you need to apply for an account.

{{Template:I18n/Language Navigation Bar|Contribute/Get a SVN Account}}
This tutorial is about how to apply for a SVN account for KDE.

== Notations ==

* The word ''SVN'' applies to all SVN servers.
* The phrase ''KDE SVN'' refers only to KDE's SVN server.
* The phrase ''anonymous SVN'' means KDE's anonymous SVN mirrors.

== What is KDE SVN? ==

To have write access to KDE SVN, you have to use the main SVN server of KDE. (Anonymous SVN uses mirrors of this server. SVN does not allow you to read from one server and write to another.)

To be able to use the main KDE SVN server, you need an account there. An account is made up of a ''username'' (normally your family name), a password and an email address. The username is for getting in, the password for authenticating and the email address for knowing who to contact if another developer wants to contact the account holder. (The username is sometimes known also as the ''login''.)

A KDE SVN account allows you to write to nearly anywhere in the KDE SVN. However, there are exceptions:
* the KDE SVN internals
* the www module (exceptions can be made for this.)

'''Note''': you can see the accounts in [http://websvn.kde.org/trunk/kde-common/accounts kde-common/accounts]. That is the list of all accounts. Yes, '''the account list is public''', for example on [http://websvn.kde.org WebSVN].

== Who Can Apply For a KDE SVN Account? ==

Normally, any developer who has done some work on KDE can apply for a KDE SVN account.

Translators should get approval from their team leader so that they can organize how the work is being done in his/her team. Please mention the approval from the team leader when requesting the account.

Please also [[Policies/SVN Commit Policy|read the KDE SVN commit policy]]. You must accept these rules when using your future KDE SVN account. Please also familiarize yourself with the [http://www.kde.org/code-of-conduct/ KDE Code of Conduct] which describes the social foundations within KDE.

Also please apply for an account only if you think that you will work on KDE for a somewhat longer time. If you know that you will only work for a couple of weeks and then never again, please consider not applying for a KDE SVN account but still, do continue to send patches.

The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.

Of course, to be clear: ''the KDE's sysadmins have the last word about whether or not to create a KDE SVN account for somebody''.

== SSH ==

You need a SSH public key in order to access your KDE SVN account. If you already have one, you can skip the next subsection and go to [[#Setting up the SVN+SSH protocol|Setting up the SVN+SSH protocol]].

=== Generating the SSH keys ===

To be able to use your KDE SVN account with SSH, you need a SSH public key. Please notice that it is '''not''' a GPG (OpenPGP) key, which is completely unrelated!

The password in the sense of this documentation is the '''public key''' that you are creating.

For more information on how to create a pair o SSH keys, please refer to a [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen SSH documentation] or book.

In short, the command to create a pair of keys is '''ssh-keygen''' and it requires the type of key you will create, either DSA or RSA - both are fine.

To create a new pair of keys, use <code bash>ssh-keygen -t dsa</code> or <code bash>ssh-keygen -t rsa</code>

There is also a type called RSA1 which was used in version 1 of the SSH protocol. See the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen ssh documentation] for more details.

You can then accept the default filename for your key (either {{path|$HOME/.ssh/id_dsa}} or {{path|$HOME/.ssh/id_rsa}}, depending on the type of key you have chosen). After that, a passphrase is asked. It is recommended that you do not leave it blank.

Now that you are finished generating your key pair, you will have two files: a private key and a public key. If you have accepted the default filename, they will be respectively {{path|$HOME/.ssh/id_dsa}} and {{path|$HOME/.ssh/id_dsa.pub}} or {{path|$HOME/.ssh/id_rsa}} and {{path|$HOME/.ssh/id_rsa.pub}}, depending on the type of key you have specified.

The private key '''must''' remain secret, do not publish it to anyone under any circumstance.

The public key can be published and shall be sent when you are applying for a KDE SVN account.

You should also set up <tt>ssh-agent</tt> so you do not have to type the password every time you connect via SSH. There are several tutorials available explaining how to do this, for example [http://mah.everybody.org/docs/ssh this one]. [http://www.gentoo.org/proj/en/keychain Keychain] is a program that makes this task easier.

'''Note''': if you already have an ssh key, you can just use the existing key instead of creating a new one.

{{tip|
If you want to use SVN with SSH with another user than the one who created the keys, you need to copy <tt>$HOME/.ssh/id_dsa.pub</tt> and <tt>$HOME/.ssh/id_dsa</tt> or <tt>$HOME/.ssh/id_rsa.pub</tt> and <tt>$HOME/.ssh/id_rsa</tt> to the other user's <tt>$HOME/.ssh</tt> directory.

You should probably also backup those files.
}}

=== Setting up the SVN+SSH protocol ===

Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE sites. Add the following lines to the <tt>~/.ssh/config</tt> file. Replace USERNAME with yours.

<pre>
Host *.kde.org
User USERNAME
IdentityFile ~/.ssh/id_dsa
</pre>

The linked IdentityFile must belong to the public key you send in when applying for the SVN account. But it is ''not'' the public key (<tt>*.pub</tt>).

== Apply for an account ==

Now you are ready to apply for for a KDE SVN account. Go to [https://identity.kde.org/ https://identity.kde.org/svnaccount/] and create an account if you don't have one already. If you already have an account, you can use that. After you entered the site you will find a form which you can fill in to apply for an account.

When you register on identity.kde.org, you will need to enter your name and an e-mail address, which has to be your own (a normal address or a KDE Mail address). Of course, do not forget that '''this email address becomes public''' (at least by [http://websvn.kde.org WebSVN]) so you will unfortunately get spam.

Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have an account in [http://bugs.kde.org bugs.kde.org], please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address of your Subversion and [http://bugs.kde.org bugs.kde.org] accounts match.

After that, you must choose a username for your KDE SVN account between the suggestions presented to you. Please notice it is not possible to propose something else such as a nickname, as the username must be as close as possible to someone's real name.

If you ask for a KDE email address one day, this will be the base for your address. For example: <tt>username@kde.org</tt>. (Note, however, that KDE email addresses are not granted so easily anymore, as too many people have ranted with a KDE address and other people thought that it was the official position of the KDE Team. In the meantime, [http://www.kdemail.net KDE Mail] was created for if you need a permanent address.)

When applying for developer access you have to provide your public key. This key will be added to your profile. You can always add more keys, delete keys you don't use anymore from your profile page on identity.kde.org.

The form also holds a field ''Why do you want an account?'', where you can explain what you want to do with your future KDE SVN account, like for example developing a certain application, making documentations or being the team leader of a translation.

Also note that the form will ask you who has encouraged you to apply. He or she will also get an email to verify your request.

== Updating Existing Account ==

If you already have a KDE SVN account but want to update the ssh key, [https://bugs.kde.org/enter_sysadmin_request.cgi send a request] to the sysadmins, selecting the "svn account" component and attaching your ssh key.

== And Now? ==

After having sent the form and clicking the link in the email, you have to wait for the answer (typically within two or three days).

Once you have confirmation that your account has been created, you need to adapt your local copy to the new server. See the [[Contribute/First Steps with your KDE SVN Account|next tutorial]] for your first steps with your new account.

Please add your geographical location (what country are you in?) and other details at the [http://commit-digest.org/data/ Commit Digest data page] so that the Commit Digest can accurately reflect who is working where.

Projects/MoveToGit/Layout

2010-09-08T21:51:11Z

Toma: /* Reviewboard */

==Definitions==
modules:
*each SC module is one repository.
*each extragear application is one repository.
*kdereview and playground are implemented with individual repos and/or branches?
*tarballs stay the same as it is now

split:
*each SC application is one repository.
*kdelibs and pimlibs are one repo each. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
*extragear and review/playground as above.
*tarballs stay the same as it is now

==Comparison==
Pros for each option (cons are rephrased as a pro for the other one)
Note: no mention of the magnitude of each point has been made yet.

===svn2git===
modules:
*some work has already been done on creating module repos
*moves within modules can be ignored

split:

===Reviewboard===
modules:
*less projects to choose from when submitting a patch? [web only, not an issue with post-review]
*no namespacing issue

split:
*if something moves to another module, no changes are needed
*ability to assign a dedicated review group per app

comments:
*the reviewer groups won't be affected

===Redmine===
modules:
*no namespacing issue

split:
*source code links are automatically available on each applicaton page, instead of the module page

===gitolite===
modules:
*no namespacing issue

split:
*easier to find projects

===git===
modules:
*projects can keep their interdependencies, module-wide libraries and so on
*less server space

split:
*moving a project (eg. to unmaintained) moves its whole history

===user workflow===
modules:
*keeps a sense of community by having a whole module kept together
*increases passive testing of trunk (more people to notice if the build's broken)
*lower barrier to hacking on other projects in the module
*easier to refactor a module [rare]
*less downloading & disk space for those who want entire modules

split:
*less downloading & disk space for people who only want a small part of a module
*easier to get started on one little app?
*easier to avoid being exposed to unstable versions of other projects [I think that's a bit selfish though]

comments:
*kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.

===releases===
modules:
*closer to what we have with svn??

split:

Projects/MoveToGit/Layout

2010-09-08T21:49:48Z

Toma: /* Definitions */

==Definitions==
modules:
*each SC module is one repository.
*each extragear application is one repository.
*kdereview and playground are implemented with individual repos and/or branches?
*tarballs stay the same as it is now

split:
*each SC application is one repository.
*kdelibs and pimlibs are one repo each. kdebase can be split on workspace/runtime/apps, where optionally apps could be split further
*extragear and review/playground as above.
*tarballs stay the same as it is now

==Comparison==
Pros for each option (cons are rephrased as a pro for the other one)
Note: no mention of the magnitude of each point has been made yet.

===svn2git===
modules:
*some work has already been done on creating module repos
*moves within modules can be ignored

split:

===Reviewboard===
modules:
*less projects to choose from when submitting a patch? [web only, not an issue with post-review]
*no namespacing issue

split:
*if something moves to another module, no changes are needed

comments:
*the reviewer groups won't be affected

===Redmine===
modules:
*no namespacing issue

split:
*source code links are automatically available on each applicaton page, instead of the module page

===gitolite===
modules:
*no namespacing issue

split:
*easier to find projects

===git===
modules:
*projects can keep their interdependencies, module-wide libraries and so on
*less server space

split:
*moving a project (eg. to unmaintained) moves its whole history

===user workflow===
modules:
*keeps a sense of community by having a whole module kept together
*increases passive testing of trunk (more people to notice if the build's broken)
*lower barrier to hacking on other projects in the module
*easier to refactor a module [rare]
*less downloading & disk space for those who want entire modules

split:
*less downloading & disk space for people who only want a small part of a module
*easier to get started on one little app?
*easier to avoid being exposed to unstable versions of other projects [I think that's a bit selfish though]

comments:
*kdesrc-build, build-tool and mr make it easy to handle large numbers of repos, although there's still room for improvement on userfriendliness.

===releases===
modules:
*closer to what we have with svn??

split:

Contribute/First Steps with your KDE SVN Account

2010-08-11T21:27:26Z

Toma: Removed https option. That's no longer possible now.

{{improve}}
This tutorial is about what to do when you are a fresh owner of a new SVN account for KDE.

== Notations ==
* ''SVN'' is used to describe an SVN server, mostly KDE's non-anonymous or anonymous SVN servers.
* The lower case word ''svn'' is used to describe the program named svn, which the user can use to access SVN.
* By ''username'' the name of your KDE SVN account is meant (also known as ''login'').

== Preliminary ==

This tutorial assumes that you have [[Contribute/Get a SVN Account|applied for a KDE SVN account as described here]] and that you have received a positive answer with the information associated with your new account.

== Read First! ==

Now you have a KDE SVN account.

Please note that the answer email will have an explanation about how to use the account. (This explanation is also the file [http://websvn.kde.org/trunk/kde-common/svn/svn_instructions.txt?view=markup kde-common/svn/svn_instructions.txt].) It contains also topics not discussed here. So please read this email.

In case of conflicting instructions, please follow those of the '''email''', not the ones of this tutorial.

== Changed URLs ==

Until now, you have worked with one of the anonymous SVN servers. Now that you have a KDE SVN account, you will not use that anonymous server anymore. Therefore the base URL to the SVN server changes for you.

For the standard anonymous SVN of KDE, it was: {{path|svn://anonsvn.kde.org}} assuming that you have not used an anonymous SVN mirror. If you have used another anonymous SVN server for KDE, then please use its URL instead.

{{Note|If you are unsure which SVN anonymous server you have used, use the <tt>svn info</tt> command to get the server URL.}}

Now the new base URL for your access to the KDE SVN server will be:
svn+ssh://username@svn.kde.org/home/kde
where <tt>username</tt> is the name that was given to your KDE SVN account.

== Changing The URLs of the Modules of Your Local SVN Copy ==
This only applies if you have local copies of SVN files that were taken from an anonymous SVN Server, otherwise skip this.

To use the KDE SVN server instead of one of the anonymous SVN servers, you need to tell each module of your local SVN copy that you want to change the server. SVN does this with the command
svn switch --relocate

Assuming that you are processing the kdelibs module, you have to use:
svn switch --relocate svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs svn+ssh://username@svn.kde.org/home/kde/trunk/KDE/kdelibs

For other modules than kdelibs (or for branches or for tags), you have to change the relative module path; similarly, if you used another anonymous server.

Be careful on what URLs you type, as SVN will only replace the exact old URL by the exact new URL. So if you mistype one of the URLs, it will not work later. (If you have already fallen into this pitfall, it is not a problem, just use relocate again to replace the wrong URL with the right one.)

You will be asked to accept the SSL certificate on the first attempt to access the server.

<code>
$ svn switch --relocate svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs svn+ssh://username@svn.kde.org/home/kde/trunk/KDE/kdelibs
The authenticity of host 'svn.kde.org (195.135.221.74)' can't be established.
RSA key fingerprint is 86:f3:66:06:20:74:81:d0:1b:b4:2f:25:03:f7:8e:fb.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'svn.kde.org,195.135.221.74' (RSA) to the list of known hosts.
</code>

Ensure that the fingerprint matches that in the document [http://techbase.kde.org/Getting_Started/Sources/Using_Subversion_with_KDE#The_KDE_repository_structure Using Subversion with KDE]. (Normally, the SHA1 fingerprint is used for HTTPS.)

== First Test ==

The following steps are described using the command line tool <tt>svn</tt>. Personally, I find it better to start with it, as you know immediately where the problems are. Of course, after you have made your first test, you may use whatever tool that you prefer.

Then you should be ready to start. The best test is to try to update a small directory. So change to a (small) directory of your local copy of KDE and type: <code bash>svn update</code>

Alternatively, if you have no local copies installed, you can just checkout a module.
<code bash>svn checkout YOUR_URL</code>
Obviously, replace YOUR_URL with the correct path.

Now you can use the SVN commands on KDE's main SVN.

{{note|If you know CVS, you will perhaps wonder that there is no <tt>cvs login</tt>, Subversion has chosen not to have such a way to login. The login is done at the first connection, where authentication is needed.}}

== Default Editor ==

This section is only useful if you plan to use the <tt>svn</tt> program. If you always plan to use a GUI front-end, you can skip this section.

When committing, <tt>svn</tt> wants some text for commenting the commit. You can either specify it directly with the <tt>-m</tt> parameter or by a file with <tt>-F</tt> or <tt>--file</tt>. If you do neither of both, <tt>svn</tt> will run an editor to ask for a comment.

* TODO: improve this section
* TODO: better ask the user to modify the svn configuration files?

This editor is taken either from the svn configuration files or if not defined there from the environment variables: first <tt>$SVN_EDITOR</tt>, then <tt>$VISUAL</tt>, then <tt>$EDITOR</tt> depending which one is defined.

So maybe you should check your environment variables:
<code bash>
echo $SVN_EDITOR
echo $VISUAL
echo $EDITOR
</code>

Check that their settings suit you for your work with svn. If they do not suit you, check your file {{path|~/.bashrc}} and add something like:
<code bash>export SVN_EDITOR=mcedit</code>
Here it sets mcedit, replace it with your favorite editor. Of course you can set <tt>$EDITOR</tt> instead if you want to change the default editor for you.

Be careful that if you do not set a command line editor but one that needs X-Window, you will need to run svn always in a X-Window terminal. It might suit you, it might not. Your choice!

== Subversion Configuration ==

For proper of ''svn status'' and ''svn diff'' on KDE sources, you might want to follow the instructions from [http://developer.kde.org/documentation/other/developer-faq.html#q1.5.2 the developer FAQ] for setting up {{path|~/.subversion/config}}.

== Committing ==

Now a few words about how to commit.

First be sure that the code that you want to commit is right. If you are not certain about a patch, or have some doubts, consider perhaps sending your patch to the relevant mailing list or to the relevant developer if you know who he is.

Also when committing, please give a useful message with the commit. Think about what you would like to find in, say, two years. (One day, you will probably find out that meaningless commit entries like "Fix" or "Here too" are going to drive you crazy when you have to debug a problem.)

Good code is not always only about questions like: "Does the code compile?" The code must also fit in what is planned. For example if a new code fixes just one little bug but the maintainer of the code is currently doing a re-write, he will perhaps not be pleased that something has been committed, because he will have to fix all conflicts between the newly committed code and his new code.

So the best is to communicate (if possible early) to avoid any surprise. A surprised developer is highly at risk of giving a rude answer or at least not a pleasant answer. This is avoidable by communication. Of course, a developer might ask to leave the code alone. Please respect that! (Of course, it does not mean that you should not argue.)

== Commit-Digest ==

The [http://www.commit-digest.org KDE Commit-Digest] is a weekly overview of the commits to KDE's subversion server. Now that you have a SVN account, you will probably see your own name in there soon!

The digest features a small statistics section. To improve the accuracy of those, you should add some information, like age or country, about yourself, which you can do [http://commit-digest.org/data here].

== Commit-Filter ==
[http://commitfilter.kde.org/ Commit-Filter] is a service which allows you to monitor folders (or authors) in SVN for changes, and have each commit's diff emailed to you. This is very useful if you are interested in getting involved in a certain sub-project of KDE and want to keep up with its development.

Please use reply-to-all when responding to those emails.

== Links ==

; Subversion
: [[Getting_Started/Sources/Using_Subversion_with_KDE|Using Subversion with KDE]]

;i18n
:[[Development/Tutorials/Localization/i18n|What is i18n and how to use it]]

; I18N/L10N
: [http://developer.kde.org/documentation/library/kdeqt/kde3arch/kde-i18n-howto.html KDE Programmer's i18n howto]

Contribute/Get a Contributor Account

2010-08-11T21:22:38Z

Toma: Removed https option. That's no longer possible now.

{{Template:I18n/Language Navigation Bar|Contribute/Get a SVN Account}}
This tutorial is about how to apply for a SVN account for KDE.

== Notations ==

* The word ''SVN'' applies to all SVN servers.
* The phrase ''KDE SVN'' refers only to KDE's SVN server.
* The phrase ''anonymous SVN'' means KDE's anonymous SVN mirrors.

== What is KDE SVN? ==

To have write access to KDE SVN, you have to use the main SVN server of KDE. (Anonymous SVN uses mirrors of this server. SVN does not allow you to read from one server and write to another.)

To be able to use the main KDE SVN server, you need an account there. An account is made up of a ''username'' (normally your family name), a password and an email address. The username is for getting in, the password for authenticating and the email address for knowing who to contact if another developer wants to contact the account holder. (The username is sometimes known also as the ''login''.)

A KDE SVN account allows you to write to nearly anywhere in the KDE SVN. However, there are exceptions:
* the KDE SVN internals
* the www module (exceptions can be made for this.)

'''Note''': you can see the accounts in [http://websvn.kde.org/trunk/kde-common/accounts kde-common/accounts]. That is the list of all accounts. Yes, '''the account list is public''', for example on [http://websvn.kde.org WebSVN].

== Who Can Apply For a KDE SVN Account? ==

Normally, any developer who has done some work on KDE can apply for a KDE SVN account.

Translators should get approval from their team leader so that they can organize how the work is being done in his/her team. Please mention the approval from the team leader when requesting the account.

Please also [[Policies/SVN Commit Policy|read the KDE SVN commit policy]]. You must accept these rules when using your future KDE SVN account. Please also familiarize yourself with the [http://www.kde.org/code-of-conduct/ KDE Code of Conduct] which describes the social foundations within KDE.

Also please apply for an account only if you think that you will work on KDE for a somewhat longer time. If you know that you will only work for a couple of weeks and then never again, please consider not applying for a KDE SVN account but still, do continue to send patches.

The limitations are not there to exclude anyone - they are there to ensure that the maintenance of accounts remains reasonable.

Of course, to be clear: ''the KDE's sysadmins have the last word about whether or not to create a KDE SVN account for somebody''.

== SSH ==

You need a SSH public key in order to access your KDE SVN account. If you already have one, you can skip the next subsection and go to [[#Setting up the SVN+SSH protocol|Setting up the SVN+SSH protocol]].

=== Generating the SSH keys ===

To be able to use your KDE SVN account with SSH, you need a SSH public key. Please notice that it is '''not''' a GPG (OpenPGP) key, which is completely unrelated!

The password in the sense of this documentation is the '''public key''' that you are creating.

For more information on how to create a pair o SSH keys, please refer to a [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen SSH documentation] or book.

In short, the command to create a pair of keys is '''ssh-keygen''' and it requires the type of key you will create, either DSA or RSA - both are fine.

To create a new pair of keys, use <code bash>ssh-keygen -t dsa</code> or <code bash>ssh-keygen -t rsa</code>

There is also a type called RSA1 which was used in version 1 of the SSH protocol. See the [http://www.openbsd.org/cgi-bin/man.cgi?query=ssh-keygen ssh documentation] for more details.

You can then accept the default filename for your key (either {{path|$HOME/.ssh/id_dsa}} or {{path|$HOME/.ssh/id_rsa}}, depending on the type of key you have chosen). After that, a passphrase is asked. It is recommended that you do not leave it blank.

Now that you are finished generating your key pair, you will have two files: a private key and a public key. If you have accepted the default filename, they will be respectively {{path|$HOME/.ssh/id_dsa}} and {{path|$HOME/.ssh/id_dsa.pub}} or {{path|$HOME/.ssh/id_rsa}} and {{path|$HOME/.ssh/id_rsa.pub}}, depending on the type of key you have specified.

The private key '''must''' remain secret, do not publish it to anyone under any circumstance.

The public key can be published and shall be sent when you are applying for a KDE SVN account.

You should also set up <tt>ssh-agent</tt> so you do not have to type the password every time you connect via SSH. There are several tutorials available explaining how to do this, for example [http://mah.everybody.org/docs/ssh this one]. [http://www.gentoo.org/proj/en/keychain Keychain] is a program that makes this task easier.

'''Note''': if you already have an ssh key, you can just use the existing key instead of creating a new one.

{{tip|
If you want to use SVN with SSH with another user than the one who created the keys, you need to copy <tt>$HOME/.ssh/id_dsa.pub</tt> and <tt>$HOME/.ssh/id_dsa</tt> or <tt>$HOME/.ssh/id_rsa.pub</tt> and <tt>$HOME/.ssh/id_rsa</tt> to the other user's <tt>$HOME/.ssh</tt> directory.

You should probably also backup those files.
}}

=== Setting up the SVN+SSH protocol ===

Once you created your key, you'll have to tell SSH that this one should be used for all connections to KDE sites. Add the following lines to the <tt>~/.ssh/config</tt> file. Replace USERNAME with yours.

<pre>
Host *.kde.org
User USERNAME
IdentityFile ~/.ssh/id_dsa
</pre>

The linked IdentityFile must belong to the public key you send in when applying for the SVN account. But it is ''not'' the public key (<tt>*.pub</tt>).

== Apply for an account ==

Now you are ready to apply for for a KDE SVN account. Go to [https://sysadmin.kde.org/svnaccount/ https://sysadmin.kde.org/svnaccount/] and fill out the form.

You will need to enter your name and an e-mail address, which has to be your own (a normal address or a KDE Mail address). Of course, do not forget that '''this email address becomes public''' (at least by [http://websvn.kde.org WebSVN]) so you will unfortunately get spam.

Also note that this email address should be the same one that you use on [http://bugs.kde.org bugs.kde.org]. If you don't have an account in [http://bugs.kde.org bugs.kde.org], please create one so that it can be given usual developer rights. Closing bug reports with keywords in commit comments only works if the email address of your Subversion and [http://bugs.kde.org bugs.kde.org] accounts match.

After that, you must choose a username for your KDE SVN account between the suggestions presented to you. Please notice it is not possible to propose something else such as a nickname, as the username must be as close as possible to someone's real name.

If you ask for a KDE email address one day, this will be the base for your address. For example: <tt>username@kde.org</tt>. (Note, however, that KDE email addresses are not granted so easily anymore, as too many people have ranted with a KDE address and other people thought that it was the official position of the KDE Team. In the meantime, [http://www.kdemail.net KDE Mail] was created for if you need a permanent address.)

Then you have to provide your public key.

The form also holds a field ''Why do you want an account?'', where you can explain what you want to do with your future KDE SVN account, like for example developing a certain application, making documentations or being the team leader of a translation.

After filling out the form, you will receive an email with a link to click on. This is done to verify your email address. The application is not complete before you click on it.

Also note that the form will ask you who has encouraged you to apply. He or she will also get an email to verify your request.

== Updating Existing Account ==

If you already have a KDE SVN account but want to update the ssh key, [https://bugs.kde.org/enter_sysadmin_request.cgi send a request] to the sysadmins, selecting the "svn account" component and attaching your ssh key.

== And Now? ==

After having sent the form and clicking the link in the email, you have to wait for the answer (typically within two or three days).

Once you have confirmation that your account has been created, you need to adapt your local copy to the new server. See the [[Contribute/First Steps with your KDE SVN Account|next tutorial]] for your first steps with your new account.

Please add your geographical location (what country are you in?) and other details at the [http://commit-digest.org/data/ Commit Digest data page] so that the Commit Digest can accurately reflect who is working where.

User:Toma

2010-07-26T18:27:50Z

Toma:

test
test

User:Toma

2010-07-26T18:27:36Z

Toma: Created page with 'test'

test

Schedules/KDE4/4.6 Release Schedule

2010-05-30T09:56:32Z

Toma: Fix typo description in the soft message freeze blurp.

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

Experimental: download as iCal format [[Media:Releaseschedulekde46.ics‎]], which you can add to korganizer...

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until the Hard Message Freeze, but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-05-27T20:51:25Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

Experimental: download as iCal format [[Media:Releaseschedulekde46.ics‎]], which you can add to korganizer...

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules

2010-05-27T19:44:37Z

Toma:

__NOTOC__

During development, the KDE project sets goals in features and dates for upcoming releases. This way, the team knows when it would be a good time to add a new feature or when it's time to
focus on cleaning up any bugs in preparation for a release. Any plans are tentative schedules and the final dates are generally decided on the kde-core-devel mailing list.

Learn more about [[Schedules/Release Schedules Guide|release schedules]].

== KDE4 ==
* [[Schedules/KDE4/Goals|KDE 4 Goals]]
* [[Schedules/KDE4/Application Porting Status|Application Porting Status]]

*'''KDE SC 4.6'''
** [[Schedules/KDE4/4.6 Release Schedule|Release Schedule]]

*'''KDE SC 4.5'''
** [[Schedules/KDE4/4.5 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.5 Feature Plan|Feature Plan]]

*'''KDE SC 4.4'''
** [[Schedules/KDE4/4.4 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.4 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.4 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.4 for you?|Is KDE 4.4 for you?]]
** [[Schedules/KDE4/4.4 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.4 Requirements|Compilation Requirements]]

*'''KDE 4.3'''
** [[Schedules/KDE4/4.3 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.3 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.3 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.3 for you?|Is KDE 4.3 for you?]]
** [[Schedules/KDE4/4.3 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.3 Requirements|Compilation Requirements]]

*'''KDE 4.2'''
** [[Schedules/KDE4/4.2 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.2 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.2 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.2 for you?|Is KDE 4.2 for you?]]
** [[Schedules/KDE4/4.2 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.2 Requirements|Compilation Requirements]]

*'''KDE 4.1'''
** [[Schedules/KDE4/4.1 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.1 Release Goals|Release Goals]]
** [[Schedules/KDE4/4.1 Feature Plan|Feature Plan]]
** [[Schedules/Is KDE 4.1 for you?|Is KDE 4.1 for you?]]

*'''KDE 4.0'''
** [[Schedules/KDE4/4.0 Release Schedule|Release Schedule]]
** [[Schedules/KDE4/4.0 Release Roadmap|Release Milestones]]
** [[Schedules/KDE4/4.0 Module_Status|Module Status and Pending Application Issues]]
** [[Schedules/KDE4/4.0 Upstream Issues|Release Critical Upstream Issues]]
** [[Schedules/KDE4/4.0 Announcements|Announcement Information]]
** [http://developer.kde.org/development-versions/kde-4.0-features.html Feature Plan]
** [[Schedules/KDE4/4.0 Requirements|Compilation Requirements]]

== KDE3 ==

*'''KDE 3.5''' [[Schedules/KDE 3.5 Release Schedule|release schedule]], [[Schedules/KDE 3.5 Feature Plan|feature plan]]

=== Previous releases ===

*'''KDE 3.4''' [[Schedules/KDE 3.4 Release Schedule|release schedule]], [[Schedules/KDE 3.4 Feature Plan|feature plan]]
*'''KDE 3.3''' [[Schedules/KDE 3.3 Release Schedule|release schedule]], [[Schedules/KDE 3.3 Feature Plan|feature plan]]
*'''KDE 3.2''' [[Schedules/KDE 3.2 Release Schedule|release schedule]], [[Schedules/KDE 3.2 Feature Plan|feature plan]]
*'''KDE 3.1''' [[Schedules/KDE 3.1 Release Schedule|release schedule]], [[Schedules/KDE 3.1 Feature Plan|feature plan]]
*'''KDE 3.0''' [[Schedules/KDE 3.0 Release Schedule|release schedule]], [[Schedules/KDE 3.0 Feature Plan|feature plan]]

== KOffice ==

=== Current releases ===

*'''KOffice 2.2''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.2/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.2/Feature_Plan feature plan]
*'''KOffice 2.1''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.1/Feature_Plan feature plan]
*'''KOffice 2.0''' [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.0/Release_Plan release schedule], [http://wiki.koffice.org/index.php?title=Schedules/KOffice/2.0/Feature_Plan feature plan]

=== Previous releases ===

*'''KOffice 1.6''' [[Schedules/KOffice 1.6 Release Schedule|release schedule]]
*'''KOffice 1.5''' [[Schedules/KOffice 1.5 Release Schedule|release schedule]]

== Extragear ==
* [[Schedules/Extragear|Overview of upcoming Extragear releases]]

== Playground ==
* [[Schedules/Playground|Overview of upcoming Playground releases]]

Schedules/KDE4/4.6 Release Schedule

2010-05-27T19:42:05Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ software]. Don't edit below, but edit the software and regenerate the schedule.)

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-05-27T19:41:50Z

Toma:

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [http://websvn.kde.org/trunk/playground/utils/releaseschedule/ | software]. Don't edit below, but edit the software and regenerate the schedule.)

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-05-27T19:41:09Z

Toma: Protected "Schedules/KDE4/4.6 Release Schedule" ([edit=sysop] (indefinite) [move=sysop] (indefinite))

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [[http://websvn.kde.org/trunk/playground/utils/releaseschedule/ | software]]. Don't edit below, but edit the software and regenerate the schedule.)

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-05-27T19:40:33Z

Toma: 4.6 schedule....

KDE SC 4.6 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

(the below schedule is generated based on [[http://websvn.kde.org/trunk/playground/utils/releaseschedule/ | software]]. Don't edit below, but edit the software and regenerate the schedule.)

== KDE SC 4.6 ==

=== Thursday, October 28, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the planned feature document. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until the next KDE SC release.

=== Thursday, November 11, 2010: Soft Message Freeze ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== Thursday, November 11, 2010: Soft API Freeze ===
To allow the bindings people to have proper time to do their work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== Thursday, November 11, 2010: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== Thursday, November 11, 2010: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== Thursday, November 18, 2010: Beta 1 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, November 24, 2010: Beta 1 Release ===
The beta becomes available for general consumption.

=== Monday, November 29, 2010: Documentatin Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== Thursday, December 2, 2010: Beta 2 Tagging ===
Trunk is frozen for beta release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== Wednesday, December 8, 2010: Beta 2 Release ===
The beta becomes available for general consumption.

=== Monday, December 20, 2010: Tagging Freeze for Release Candidate 1 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Monday, December 20, 2010: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== Monday, December 20, 2010: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok beforehand from kde-i18n-doc for every single string change.

=== Monday, December 20, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== Tuesday, December 21, 2010: Release Candidate 1 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, December 22, 2010: Release Candidate 1 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Monday, January 3, 2011: Tagging Freeze for Release Candidate 2 ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the affected maintainers as reviewer.

=== Tuesday, January 4, 2011: Release Candidate 2 Tagging ===
Trunk is frozen for release candidate tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 5, 2011: Release Candidate 2 Release ===
The release candidate is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed.As soon as the RC has been confirmed to build it will be released immediately.

=== Wednesday, January 19, 2011: Final Tag ===
The branch is frozen for final release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== Wednesday, January 26, 2011: Release ===
Final release is released for general consumption.

Development/Tutorials/Akonadi/CreatingAccountWizardPackages

2010-05-18T21:34:29Z

Toma: Add the tutorial. Someone good at wiki markup?

This short tutorial shows you how to create an accountwizard packages.

Such a package can be usefull for your users. You can put it up a shared network drive, or on some internet. The user clicks on it. The assistant pops up, asks the name and the email address of the user and all the needed accounts or resources are created automatically. You can also ask additional information, like age, or whatever you like.

A step-by-step howto:

1) Think of a name and stick to it. Say for example, your company is called 'Galactica'. The name of the package could then be just that. But remember to use it everywhere: galactica.desktop ends up in a galactica subfolder and the package is called galactica.awp.

2) Create a folder called galactica and create the files. You can get an example of the files from http://akonadi.kovoks.nl/kovoks/, rename them all, you can skip the .gif, as that won't work for now.

3) The .ui file can be edited with qt's designer. In this dialog you can ask additional information. Don't ask fullname, password or emailaddress, that will be asked on the first page of the wizard.

4) The .js file holds the intelligence to create the resources based on the gathered information. There you can also access the information which is in the .ui file, if you added that. A clearer example for this is in the kolab wizard, you can see the files here: http://websvn.kde.org/trunk/KDE/kdepim/runtime/resources/kolabproxy/wizard/ (click on the item in the revision kolom to see the contents).

Tip! Debugging the .js file is a real PITA unfortunately. Take baby steps, test a lot and don't get frustrated. If you do a lot of changes in one go, without testing, you will never know which change caused the error.

5) Adjust the .desktop file too.

6) go to the main folder, that should hold the galactica subfolder. Create the package with 'tar -cvf galactica.awp galactica'. Now your package is ready. Test it with accountwizzard --package /path/to/galactica.awp. Remember to use the full path to the file.

Projects/PIM/Akonadi

2010-05-18T21:13:55Z

Toma: /* Links */

== Akonadi TODO ==
The following list contains the things which need to be done for Akonadi.

Note: The person noted in the "Contact" column is not necessarily the one implementing that feature, but the one who can tell you what to do and how to help, i.e. you can also contribute to those tasks ;-)

There is also a more detailed page about bugs and missing features of things that are currently ported [[Projects/PIM/Akonadi/PortingStatus|here]].

=== Core ===

==== KDE 4.1 / Akonadi 1.0 ====

Urgent tasks that need to be finished for the KDE 4.1 release ('''May 19th'''):

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureDone|Item streaming in ItemSync/ResourceBase|As discussed in Osnabrueck|Tom/Volker}}
{{FeatureDone|Payload serialization format versioning|see below
tokoe@kde.org|Tobias}}
{{FeatureDone|API for additional item parts|As discussed in Osnabruck|Volker/Tobias}}
{{FeatureDone|Infrastructure for showing additional dialogs from agents/resources|As discussed in Osnabrueck|Tom}}
{{FeatureDone|Allow to limit ItemFetchJob to current cache content|Prevents search index feeder agents from downloading all remote data|vkrause@kde.org|Volker}}
{{FeatureDone|Fix API for item/collection modifications|See Osnabrueck meeting notes for details|vkrause@kde.org|Volker}}
{{FeatureDone|Plugin Versioning|For serializer plugins, also check using Qt plugin stuff instead of the libkdepim plugin framework|tokoe@kde.org|Tobias}}
{{FeatureDone|Tray app|small app to control the server and have a something that can report errors|tomalbers@kde.nl|Toma}}
{{FeatureDone|Backup support|Dump & Restore database contents, also useful when upgrading to a newer database version|tomalbers@kde.nl}}
{{FeatureDone|Akonadi Artwork|Icon for the tray app|tomalbers@kde.nl|Toma}}
|}

==== KDE 4.2 / Akonadi 1.1 ====

That's the stuff we want to have in 4.2, very roughly ordered by priority. Releases are scheduled for early January 2009.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureDone|Server error reporting|Helpful error message when the server cannot be started or if there is some other problem communicating with it.|vkrause@kde.org|Volker}}
{{FeatureDone|KResource migration tool|For KABC and KCal resources, setting up Akonadi <-> KResource bridges where needed|Volker}}
{{FeatureDone|KResource bridges|Basically finished, needs more testing|Kevin}}
{{FeatureDone|Distribution Lists|Serializer Plugin and resource support|Tobias,Kevin}}
{{FeatureDone|Complete iCal resource|error handling, robustness, legacy formats, file montitoring|Volker}}
{{FeatureDone|Complete vCard resource|same as iCal + binary legacy format|Bertjan}}
{{FeatureDone|Item size|Needed by Mailody|toma@kde.org}}
{{FeatureDone|LINK/UNLINK commands|Managing item references in virtual collections|vkrause@kde.org|Volker}}
{{FeatureDone|Akonadi Testrunner|Running tests in a self contained Akonadi setup|igor_trindade@yahoo.com.br|Igor}}
{{FeatureDone|Remote file support for iCal/vCard resources|Replaces net/remote KRes resources|Bertjan}}
{{FeatureDone|Solid integration|Switch online/offline state in ResourceBase automatically|Bertjan}}
|}

==== KDE 4.3 / Akonadi 1.2 ====

Stuff that went into KDE 4.3 and Akonadi server 1.2.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureDone|Fix unit tests|Make unittests work without destroying the production database|Igor/Volker}}
{{FeatureDone|Filesystem Backend|Store content data in files instead of the database, transfer filehandles instead of data to the client|Andras}}
{{FeatureDone|IMAP resource||Kevin}}
{{FeatureDone|Kolab proxy resource||Andras}}
{{FeatureDone|RID based operations|Item/collection retrieval and modification based on remote identifiers|Volker}}
{{FeatureDone|Microblog Support|Type library, serializer plugin, identi.ca/twitter resources|Tom}}
{{FeatureDone|ResourceBase::collectionsRetrievalDone is missing|I'm working around by calling collectionsRetrievedIncremental() with empty collection lists|Volker}}
|}

==== KDE 4.4 / Akonadi 1.3 ====

The following is being worked on for KDE 4.4 and Akonadi server 1.3.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureDone|Port KAddressBook|Replace with KContactManager|Tobias}}
{{FeatureDone|Resource testing framework|Automated, shareable tests for resources|Igor/Volker}}
{{FeatureInProgress|Review change notifications|See the various discussions about shortcomings in that area|Volker,Steve}}
{{FeatureDone|Collection statistics for sub-trees|Provide a CollectionStatus object covering the full sub-tree in the model, allowing accumulated unread counts etc.|Kevin}}
{{FeatureDone|Favorite Folder Model|see current KMail|Kevin}}
{{FeatureDone|Batch jobs for modifying/deleting collections/items|it would be great to have jobs which perform operations on several entities in one go|Volker}}
{{FeatureDone|Collection streaming support in ResourceBase/CollectionSync|Similar to what is available for items already|Volker}}
{{FeatureDone|MBox resource||Bertjan}}
|}

==== Scheduled for KDE 4.5 / Akonadi 1.4 ====

Stuff that is planned for inclusion in 4.5, partly already available in the akonadi-ports branch.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureInProgress|Port KOrganizer|Port from KResource to Akonadi|Frank/Sebastian}}
{{FeatureDone|Account creation wizard|as discussed in Berlin, see below|Volker,Laurent,Tom}}
{{FeatureInProgress|KMail port|KMail using Akonadi|everyone}}
{{FeatureInProgress|Remote Search|Delegating searches to resources, see below|Volker}}
|}

==== Post KDE 4.5 /Akonadi 1.4 ====

This stuff is currently not considered for 4.5 due to lack of resources. Of course it will be added nevertheless if someone implements it. The list is completely unsorted.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureTodo|Error reporting|Akonadi::Job basically has only one error code: Unknown|Tobias}}
{{FeatureInProgress|Port KNotes|File resource, serializer plugin, KNotes application, Kontact plugin|}}
{{FeatureTodo|Batch job to retrieve a set of items from Akonadi|Those items don't belong to the same collection, rather they are located in different collections|}}
{{FeatureTodo|CollectionFetchJob/ItemFetchJob should be able to retrieve entities by flags/mimetype|
This is problematic with change notifications, as they have to know about the filtering with the \Seen flag as well.
This type of filtering would be possible with full Nepomuk interface though. We don't want yet another query language here. The plan is to fix the nepomuk agent and use that as semi-public interface for now.|}}
{{FeatureTodo|Nepomuk integration|Generic Item tag/rate/comment, etc.|Tom}}
{{FeatureTodo|Sync collection tree after creating setting up a resource|see AgentInstanceCreateJob|}}
{{FeatureTodo|Support standard commands for QUndo framework||}}
{{FeatureTodo|Conflict detection in resources|See Osnabrueck meeting notes for details|}}
{{FeatureInProgress|Action framework|see below|vkrause@kde.org|Volker}}
{{FeatureInProgress|Fix API docs|The libakonadi move as well as the huge API changes following it broke lots of the docs technical and content-wise, see below|Tobias}}
{{FeatureInProgress|Migration|Data and settings from pre-Akonadi times, see below|}}
{{FeatureInProgress|Extended notifications|Item change notification do not yet include their source collections (real and virtual)|}}
{{FeatureTodo|Alternative for Akonadi::ResourceBase|Not using the scheduler to avoid the serialization of operations, see RSS resource. (This will get very complicated. Maybe use a proxy ResourceBase for this, which is thread-pooled?)|}}
|}

=== Supported Types ===

Overview on the current state of support for various types:

{|
|-
! Type !! Serializer !! Multipart Support !! Models !! Views !! Resources !! Notes
|-
|Email||yes||partial||MessageModel, MessageCollectionModel, threading proxy model||?||maildir, IMAP||threading agent
|-
|News||yes (1)||partial (1)||(1)||(1)||NNTP||
|-
|Contact||yes||no||ContactModel||-||vCard, facebook, KRes||
|-
|Events||yes||no||EventModel||-||iCal, KRes||
|-
|Notes||no||no||-||-||-||not started yet
|-
|Feeds||yes||no||Feeds, Items||?||OPML||GSoC in playground/pim
|-
|Bookmarks||yes||no||-||-||local bookmarks, del.icio.us||
|}

(1) see Email

=== Mail specific extensions ===

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureTodo|Share mail flag code|Standard actions, standard flag enum/constants, Nepomuk interaction|}}
|}

=== Event/Todo/Journal specific extensions ===

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureTodo|Todo proxy model|See KOrganizers To-Do view|Bruno?}}
{{FeatureDone|Subtype identification|See discussion on kde-pim mailinglist|Kevin}}
{{FeatureInProgress|Agenda view|KOrganizer agenda view based on Akonadi|Sergio,Kevin}}
{{FeatureTodo|Month view|KOrganizer month view based on Akonadi|Bruno?}}
{{FeatureTodo|Timeline view|KOrganizer timeline view based on Akonadi|}}
|}

=== Resources, Agents and others ===

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureDone|KResource Akonadi bridge|for applications using KCal or KABC|kevin.krammer@gmx.at|Kevin}}
{{FeatureDone|Akonadi KResource bridge|for data accessed through KCal or KABC resources|kevin.krammer@gmx.at|Kevin}}
{{FeatureTodo|Expire Agent||}}
{{FeatureDone|MBOX Resource||Bertjan}}
{{FeatureDone|Extend IMAP Resource||Kevin/Andras}}
{{FeatureInProgress|POP3 Resource||Thomas}}
{{FeatureInProgress|RSS Resource|in akonadi-ports branch ([[Projects/PIM/RSS_framework_for_Akonadi|Details]])|Dmitry/Frank}}
{{FeatureInProgress|Filter Agent||Szymon}}
{{FeatureTodo|Search||}}
{{FeatureTodo| History resource||}}
{{FeatureInProgress|Filter Rule GUI|Used by filters and searches|Szymon}}
|}

Resource status overview (this should list all resources existing in KDE3 or already under development for Akonadi):

{|
|-
! Resource !! Retrieve Collections !! Retrieve Items !! Change Collections !! Change Items !! Configuration !! Notes
|-
|iCal||yes (4)||yes (1) (2)||no||yes||yes||remote file support, file watching with conflict handling
|-
|vCard||yes (4)||yes (1) (2)||no||yes||yes||remote file support, file watching with conflict handling
|-
|maildir||yes (1) (4)||yes (1) (2)||?||?||yes||
|-
|mbox||no||no||no||no||no||not started yet, code exists in KMail
|-
|IMAP||yes (1) (4)?||yes (1) (2)||no||no||no||code exists in kio_imap4 and Mailody, support for extensions: quota, ACL, annotations missing, what about Kolab and Scalix?
|-
|NNTP||yes (4)||yes (2)||n/a||n/a||yes||Needs support for local collection names and collection hierarchy
|-
|Local Bookmarks||?||?||?||?||(3)||Code in akonadi/resources
|-
|OpenChange||?||?||?||?||?||Code in akonadi/resources
|-
|Facebook||?||?||?||?||?||Code in playground/pim
|-
|del.icio.us||?||?||?||yes||no||Code in playground/pim
|-
|KABC||yes(6)||yes||no||yes||yes||
|-
|KCal||yes(6)||yes||yes(7)||yes||yes||
|}

# only full sync supported currently, need optimization
# does not yet honor cache policy
# still relies on QSettings for configuration and/or doesn't provide configuration over D-Bus
# does not yet provide correct access control settings
# only adding new items, not changing existing ones
# availability of child collections depend on whether the KResource plugin has subresources
# child collections can be added or removed if the KCal plugin can have subresources

=== KResource Migration Status ===

Everything without migration support is implicitly converted to use the compat bridge currently.

[[Image:Akonadi-Kres.png]]

==== KABC migration status ====

{|
|-
! KResource !! Feature equivalent agent !! Migration support !! Notes
|-
|directory|| || ||vCard dir in development
|-
|file||vCard file||4.2||binary format no longer supported, migrated to compat bridge instead
|-
|groupdav||||||
|-
|groupwise||||||
|-
|kolab||||||
|-
|ldapkio||||||
|-
|net||vCard file||TODO||
|-
|scalix||||||
|-
|slox||||||
|-
|xmlrpc||||||
|}

==== KCal Migration Status ====

{|
|-
! KResource !! Feature equivalent agent !! Migration support !! Notes
|-
|blog||||||
|-
|bugzilla||||||
|-
|groupdav||||||
|-
|groupwise||||||
|-
|kabc (birthday)||birthdays||4.3||
|-
|kolab||||||
|-
|localdir||||||
|-
|local||iCal file||4.2||
|-
|remote||iCal file||TODO||remote supports different URLs for upload and download, the iCal file agent doesn't, is this needed at all?
|-
|featureplan||||||probably obsolete since we don't use the XML featureplan anymore
|-
|scalix||||||
|-
|slox||||||
|-
|xmlrpc||||||
|}

== Akonadi Braindump ==
Ideas/notes etc. on various open issues in Akonadi.

=== Akonadi Standard Actions ===

Idea: Have something like KStandardAction for Akonadi that not only includes the representation of the action but also its state management and the actual operations. Like libakonadi that should be splitted into a generic, type-independent part and be extensible for type-specific actions. This will enable code sharing among many applications and guarantee consistent actions everywhere.

State management: watch selection models of a collection and/or item model.

Use KXMLGUI for context menus in standard views to allow easy extensibility with custom actions.

Generic actions:
* new collection [done]
* new virtual collection
* delete collection [done for single selection]
* copy collection [done]
* cut collection
* paste collection [done]
* synchronize collection [done for single selection]
* synchronize resource
* synchronize everything
* show collection properties dialog [done]
* delete item(s) [done]
* copy item(s) [done]
* cut item(s)
* paste item(s) [done]
* paste native data
* tag item(s)
* comment item
* rate item(s)
* configure resource
* add resource? (would need a type parameter, etc.)
* delete resource
* manage local subscriptions [done]
* move to submenu
* copy to submenu

The list is definitely long enough to make this worthwhile.

=== Collection Model / Collection View ===

Ideas/missing features/bugs of the collection model/view:

* Enable/disable status columns
* Show status after the name (see KMail)
* <s>Size column</s>
* Save/restore layout
* <s>Custom collection icons (see KMail, also needed for resource defined special folders (eg. Inbox)</s>
* Status tooltips (see KMail in 3.5.9) [still missing quota info]
* Quick search
* <s>Favorite folder view as proxy model on top of the normal collection model (FlatCollectionProxyModel might be helpful for there)</s>
* Accumulated statistics (unread, total, size)
* Fix dnd: move/copy/cancel menu always shows up and never has any effect

=== Compatibility ===

Notes on how to keep long-term protocol, source and binary compatibility.

* <s>Detect server version in Akonadi::Session, might be useful in case of protocol extensions/changes</s>
* What about database server version updates?
* <s>Versioning or any other kind of serialization format meta data, we'll need that in case of changes in serialization formats (see eg. Robert's compression patch where this is needed)</s>
* <s>We currently use 32 bit ids, probably hard to change later on, is that enough?</s>
* <s>Plugin versioning</s>

=== Resource API issues ===

Notes/ideas/complaints about the Akonadi::ResourceBase API:

* Extremely error prone:
** Scheduler dead-locks when a requested operation is not correctly announced as finished, esp. a problem in error cases.
** Using the result methods multiple times or when not requested asserts
* <s>Item streaming is missing, requiring all data to be in memory at once</s>
* Non-incremental updates need to know the results of ItemSync to not have to provide all data, even for already existing/unchanged items.

=== API / BC issues ===

Smaller stuff that should be fixed before the ABI freeze and is not yet listed above:

* Cleanup the D-Bus format used by NotificationMessage
* No mentioning of "IMAP" in the public API, we are not using IMAP
* Naming and installed location of libraries, headers and executables (see discussion on kde-pim ML)
* <s>Payload part labels are QStrings, attribute types are QByteArray</s>

=== Deployment issues ===

* Multiple access: Should multiple Akonadi instances' mysqlds access a single set of data files the mysql will likely corrupt the data. This can happen in any NFS+YP installation where users can log onto any machine and access shared homes. MySQL relies on filesystem locking to prevent multiple access. [http://dev.mysql.com/doc/refman/6.0/en/multiple-servers.html MySQL multiple instance docu].
* [http://dev.mysql.com/doc/refman/6.0/en/innodb-restrictions.html InnoDB tables should not be used on NFS].
* NFS speed: MySQL documentation recommends against locating its data files on network shares.
* AppArmor: Distros' AppArmor profiles prevent MySQL from writing outside its defined data directory (usually /var/lib/mysql). This is a problem at least with *buntu and openSUSE. These will need to be adapted. It is possible to daisy-chain profiles so that MySQL started by Akonadi receives a different profile to MySQL running standalone. An empty profile has all rights. Another possibility is to adapt the general MySQL profile so it can write to ${XDG_DATA_HOME}/akonadi(usually ${HOME/}.local/share/akonadi). Both support for profile chaining and ${HOME} may depend on the version of AppArmor installed. What about SELinux?
* Backup: MySQL data files should not be backed up without telling the mysqld process, otherwise a corrupt backup will be made. LOCK TABLES and FLUSH TABLES at the least. A dump can be made or mysqlhotbackup may be used in some circumstances. We should consider sysadmins' backup techniques when planning/promoting Akonadi, as a simple rsync cronjob with running Akonadi will not work. [http://dev.mysql.com/doc/refman/6.0/en/backup.html MySQL backup advice].

=== Account Creation Wizard ===

Notes on the resource configuration wizard discussion.

* WizardBase class
* Wizard discovery via .desktop files
* A wizard can configure multiple resources (eg. IMAP + LDAP for Kolab) and non-resources (mailtransport)
* Optionally hide resources completely covered by wizards in the Add Account dialog
* List wizards in the Add Account dialog
* Store Account -> Resources information to offer deletion of depending resources

=== PostgreSQL Support ===

Has been merged for Akonadi server 1.3. We still need a volunteer for continuous testing and maintenance though.

=== Documentation ===

* Avoid examples using KJob::exec() due to its problematic side-effects.
* Examples in the ItemCreateJob docs (and maybe others) operate on items in the root collection which does not work at all
* Resurrect the server API docs
* Content of http://api.kde.org/4.x-api/kdepim-apidocs/akonadi/html/index.html should probably be moved to server or client lib docs

=== Migration of pre-Akonadi data and settings ===

* KCal/KABC
** switch KRes resources to Akonadi KRes compat resources, use KRes Akonadi compat resource, basically injecting Akonadi inbetween
** Replace Akonadi KRes compat resources with their ported equivalent
** Application side does not need migration code, "only" port to Akonadi
* KMail
** Should migrate to one resource per account + one for previous local folders
** Problem: local folders are mixed mbox/maildir
*** Dedicated KMail compat resource?
*** Convert everything to maildir first?
** Flags are stored in proprietary binary format
* KNode
** Migrate every account to NNTP resource
** Local flags should be preserved, stored in proprietary binary format
** Local subscription state should be preserved (where is that stored?)
** Local folders using MBOX format + proprietary binary index
* Akregator

=== Search & Virtual Collections ===

Got their own page by now:
* [[Projects/PIM/Akonadi/VirtualCollections]]
* [[Projects/PIM/Akonadi/SearchInfrastructure]]

== KMail Breakdown Plan ==
The current plan is to put some parts of KMail into a stand-alone
library, independent of KMail. This increases code reuse (for example, the message composer could be shared with Mailody) and makes the code a lot easier to maintain and to port to Akonadi.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureTodo|Bodypart formatters||}}
{{FeatureDone|Reader Window||Andris}}
{{FeatureDone|Composer: Message Composer||Constantin,Leo}}
{{FeatureInProgress|Composer: GUI Window||Constantin}}
{{FeatureDone|Queue Manager for mailtransport||Constantin}}
{{FeatureInProgress|Templates: Core||Leo}}
{{FeatureTodo|Templates: GUI||}}
{{FeatureTodo|Port KMCommands||}}
{{FeatureDone|Port away from KMMessage and KMFolder* everywhere it is left|An idea might be: wrap KMMsgBase/KMMessage inside a reference counted Message class. Insulate everything else from it by wrapper functions. KMFolder should be easier...|all}}
{{FeatureInProgress|Migration application for index and other config||Casey}}
{{FeatureTodo|Port MDNs||}}
|}

== The Road to World Domination ==

Sort of related so the stuff above but with a scope for all of KDE PIM and beyond.

{| class="sortable" border="1" cellpadding="5" cellspacing="0" style="border: gray solid 1px; border-collapse: collapse; text-align: left; width: 100%;"
|- style="background: #ececec; white-space:nowrap;"
! Status !! Item !! Description !! Contact
{{FeatureTodo|Share identity config GUI parts|eg. the signature configuration widget|}}
{{FeatureDone|Mailtransport Agent|Global shared outbox, central mail sending instance|Constantin}}
{{FeatureTodo|Recently sent to support in mailtransport|related to above, based on Akonadi/Nepomuk|}}
{{FeatureInProgress|Composer engine|Shared stuff for KMail/KNode/Mailody: Crypto, editor, editor actions, attachment model, message assembly, etc.|Constantin,Leo}}
|}

== Akonadi FAQ ==

This FAQ primarily deals with technical and design questions, if you have questions about using Akonadi (such as "I get error X when starting Akonadi"), please refer to [http://userbase.kde.org/Akonadi userbase.kde.org/Akonadi].

=== Where do I find the Akonadi config files? ===

''~/.config/akonadi/''

=== Where does Akonadi store my data? ===

Akonadi merely acts as a cache for your data, the actual content stays where it has always been, .ics/.vcf/MBOX files, local maildirs, IMAP- and groupware servers. There is only a limited amount of data stored exclusively in Akonadi:
* Data not supported by the corresponding backends, such as email flags in case of maildir/mbox. This is comparable to KMail's binary index files stored alongside these files in pre-Akonadi times.
* Internal meta-data used by application or resources, such as information about the last synchronization with a backend or translated folder names.
* Data that has been changed while the corresponding backend has been offline and has not yet been uploaded.

=== Where can I find the Akonadi database? ===

''~/.local/share/akonadi/''

=== Where can I find the source code? ===

There are three different parts of source code:
* The Akonadi server, which is KDE-independent. Currently, the code can be found at [http://websvn.kde.org/trunk/kdesupport/akonadi/ kdesupport/akonadi]. The server code will likely move to the [http://www.freedesktop.org/wiki/ freedesktop.org project] in the future, the move has already been [https://bugs.freedesktop.org/show_bug.cgi?id=15711 requested].
* The Akonadi KDE client libraries are in [http://websvn.kde.org/trunk/KDE/kdepimlibs/akonadi/ kdepimlibs/akonadi].
* Various agents, resources, the Akonadi console and much other misc stuff is in [http://websvn.kde.org/trunk/KDE/kdepim/akonadi/ kdepim/akonadi]

=== Where can I find documentation? ===

The documentation is mainly in the code itself, in the form of doxygen comments.
You can find the generated documentation on [api.kde.org api.kde.org], for example:

* General documentation, including a design overview, is [http://api.kde.org/4.x-api/kdepim-apidocs/akonadi/html/index.html here]

: Note that some links in the above documentation which point to the server or the KDE client libraries are currently broken, use the links below to access that documentation.
* Documentation for the KDE Akonadi client library is [http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/index.html here]
* Documentation about the server is [http://api.kde.org/kdesupport-api/kdesupport-apidocs/akonadi/server/html/index.html here]

=== Which DBMS does Akonadi use? ===

So far only MySQL. There is some work on PostgreSQL support going on though. Basically, every database that is supported by QtSQL can be used, requiring minimal changes in the code at most. However, not all of them provide the features needed by Akonadi (see next two questions).

=== Why not use sqlite? ===

We tried. Really. It can't handle the concurrent access very well, in the best case this means ''very'' slow operations, but we've also seen deadlocks and failing transactions. Once that's fixed in sqlite, adjusting Akonadi to use it again instead of MySQL is no problem.

=== Why not use MySQL/Embedded? ===

We tried that as well, there are two reasons for not using it: No support for the InnoDB engine (which we need for transaction support) and poor availability (only OpenSUSE provided usable packages, needed a patched QSQL driver).

=== Do I need a running MySQL server? ===

No. Akonadi starts its own local MySQL server (unless configured otherwise, see next question). All you need is having the 'mysqld' binary installed at runtime (usually found in the mysql-server package of your distribution).

=== Can Akonadi use a normal MySQL server running on my system? ===

Yes, it can. You find the corresponding settings in ''~/.config/akonadi/akonadiserverrc''.

=== Can I connect multiple Akonadi instances to the same database to share my data between different machines? ===

That does not work unfortunately. Akonadi does not store all relevant data in the database but also uses the file system for configuration and large payload data for example. Also, there is no mechanism to ensure multiple instances have exactly the same version and exactly the same agents and plug-ins installed etc., all of which would be necessary to work on the same database. Finally, there is no notification system to inform the other instances about changes which endangers consistency since the Akonadi server contains internal caches of data in the database. If you want multiple instances to synchronize, use a groupware server (not as bad as it sounds, Kolab for example works with many normal IMAP servers).

If you try this despite the warnings, be aware that there is no safety mechanism in place to prevent you from doing that and you will likely mess up your data in funny ways.

=== I don't like a database server because of backups/running on NFS/etc. ===

See section "Deployment Issues" above, we are aware of that and working on it. Some of these, like backup/restore are already implemented. But please be aware that most of this issues also existed before (eg. with KMail's custom binary indexes).

=== Can a single Akonadi instance be used by multiple users? ===

No. There has to be one Akonadi server instance per user. However, it is possible to use a shared database server.

=== Can I access the Akonadi server on a remote machine? ===
No. Akonadi is not a groupware server. It's a local cache only.

=== What's the differences between Akonadi and EDS? ===
EDS is limited to contacts and calendar data, Akonadi is type-independent. Especially, Akonadi is designed to also handle high-volume data such as email. Akonadi and EDS also differ largely in their access protocol on a technical level (Corba/D-Bus vs. local socket with IMAP-like protocol/D-Bus) and also on a protocol level (type specific vs. generic).

=== How do I create a collection? ===

From the developers point of view, there is Akonadi::CollectionCreateJob for that, from the users point of view, most applications allow that, eg. Mailody or akonadiconsole.

However, there is one limitation: Top-level collections can only be created by resources, not by normal applications. The reason for that is that every object (collection or item) is supposed to have an owning resource, that is a resource that is responsible for storing and retrieving that object. There is an ongoing discussion to remove this restriction though.

So, if you want to create a collection eg. for testing purposes, add a resource first. Most Akonadi applications offer an option to do that, a module for KControl is planned as well.

=== How do I disable automatic migration from KDE's traditional framework? ===

The migration tool is controlled by standard KDE configuration file called ''kres-migratorrc''.

Distributors or system administrators wanting to disable the automatism will probably want to that globally, e.g. by editing the installed default configuration file, or by using KDE's configuration hierachy and using a profile config between that and the user level.

The quickest way to deactivate it for one user account only is to use KDE's ''kwriteconfig'' tool to set the respective configration value with a simple copy&paste of the following command:

''kwriteconfig --file kres-migratorrc --group Migration --key Enabled --type bool false''

Please note that at some point KDE applications such as Kontact, KOrganizer, KMail will be using Akonadi directly, at which point migration either has to be enabled or performed manually.

As of KDE 4.4 (and its development releases and when building from SVN trunk) this already applies to KAddressBook and KMail's address book access.

=== How do I completely disable Akonadi startup? ===

{{warning|If you already have applications natively using Akonadi, you of course can't disable Akonadi startup. KAddressBook (as of KDE 4.4 and its test versions), Mailody, KMail (as of KDE 4.4 and its test versions for address book related things) and KPilot are applications that are already based on Akonadi.}}

Other applications, like KOrganizer, are not based on Akonadi yet, at the time of writing. Instead, they use the old KResource framework for storing contacts, calendars and notes.
During the KDE 4.2 beta time, these KResources were automatically migrated to Akonadi-based KResources, the so-called Akonadi compatibility resources. Therefore, applications like KOrganizer would use Akonadi indirectly through KResources, and therefore would start the Akonadi server when being started.

If Akonadi doesn't start up correctly for you, the following should help you to disable Akonadi startup and use your old KResources again.

First, disable automatic migration like described in the above FAQ entry.
Then, open System Settings, go to the Advanced tab and open the KDE Resources config panel. There, you can configure which type of KResources are used for contacts, calendars and notes. If the migration to Akonadi was successful, you'll probably only see the Akonadi Compatibility Resource as an active resource, and all others disabled.

To disable Akonadi startup, enable your old resources again, then disable and delete the Akonadi compatibility resource.

=== What is the relation between Akonadi and OpenSync? ===

Akonadi and OpenSync focus on different aspects and complement each other. Akonadi provides a unified way to access PIM data for applications and a framework to implement powerful connectors to varies data sources. OpenSync focus is on syncing two sets of PIM data.

An Akonadi plugin for OpenSync is currently under development, allowing to sync PIM data available through Akonadi with any other system supported by OpenSync, especially mobile phones.

=== When should I use Akonadi? ===

More precisely, when should you use for your application specific data instead of eg. just using a local file directly.

Akonadi is especially useful when you need one the following:

* Different backends for your data, like eg. a local file and a remote server. Akonadi provides a unified interface for application developers to access your data independent of the actual backend.
* Caching and change replay of remote data. Akonadi has support for that built in, giving you free offline support for any remote backend.
* Desktop-wide sharing of your data. As soon as more than one application (say your main applications and a plasmoid) accesses the same data you need to deal with locking, conflict detection, change notifications, etc. - or let Akonadi do that for you.

However, if you are just looking for a simple way to store your application data without needing one of the above, using Akonadi usually means more implementation work for relatively little gain.

=== Akonadi needs too much space in my home directory! ===

An empty, unused Akonadi database needs about 100 Mb of disk space. This is due to the MySQL InnoDB log files which work similar to a journal in a modern file system. These files are constant in size and independent of the actual data stored in Akonadi. The default size is optimized for performance on average desktop hardware where the use of 100 Mb of disk space is no problem. In other cases, such as multi-user systems or embedded devices, this default might not be optimal though.

The default size can be configured, globally or per-user. The global configuration file can be found in $PREFIX/share/config/akonadi/mysql-global.conf, the per-user file is in ~/.config/akonadi/mysql-local.conf and overwrites settings of the global file. In any of these files, you can change the settings '''innodb_log_file_size''' and assign it a smaller value than the default (64M).

For this setting to take effect you need to restart Akonadi. With older Akonadi versions (<=1.1.1) you might need to manually remove the InnoDB log files from ~/.local/share/akonadi/db_data for this change to take effect. The log files do not contain data after a clean shutdown and thus can safely be removed while Akonadi is not running.

An alternative approach especially for multi-user systems might be the use of a single, global MySQL server instance.

=== My Akonadi resource seems to randomly hang/stop working! ===

A very common problem of resources based on Akonadi::ResourceBase are "unguarded exit paths" from one of the methods you have reimplemented there. See the following example:

<code cpp>
void MyResource::retrieveItems( const Collection &collection )
{
if ( someError )
return;
itemsRetrieved( myItems );
}
</code>

In case of an error you leave retrieveItems() without telling Akonadi::ResourceBase that you are done with the task. Therefore, it is assumed the requested item retrieval takes a bit longer (which is not uncommon for resources for remote backends, results typically come in in a result slot connected to a job class for example) and waits until you announce the task is finished.

The following example does it correctly:

<code cpp>
void MyResource::itemAdded( const Akonadi::Item &item, const Akonadi::Collection &parent )
{
if ( noNetwork ) { // transient error
deferTask( i18n( "Offline, will retry later." ) );
} else if ( item_not_valid ) { // permanent error
cancelTaks( i18n( "Got invalid crap, can't store that." ) );
} else {
// store the item here
Item newItem( item );
newItem.setRemoteId( my_new_remote_id );
changeCommitted( newItem );
}
}
</code>

The following methods require explicit notification that a task has been completed:
* retrieveX
* any method indicating changes, ie. itemAdded|Changed|Moved|Removed(), collectionAdded|Changed|Moved|Removed()
* any custom task scheduled with ResourceBase::scheduleCustomTask()

Refer to the API documentation of Akonadi::ResourceBase for the various ways to do that correctly, there are a few different ways, depending on the current task:
* Successful completion with convenience features, eg. changeCommitted(), itemsRetrieved() etc.
* Error cases with convenience features, eg. cancelTask(), deferTask()
* Only indicate completion, with everything else done manually, eg. changeProcessed(), taskDone()

To confirm a resource is affected by this problem, the "Resource Schedulers" tab of akonadiconsole is very useful (needs to be enabled in the context menu first, causes too much slowdown otherwise). It shows the state of the internal task scheduler of your resource, allowing you to spot stuck tasks.

[[Category:PIM]]

== Links ==

* [[Projects/PIM/Akonadi/Testing|Akonadi Testing Framework]]
* [[Projects/PIM/Akonadi/Development_Tools|Akonadi Development Tools]]
* [[Projects/PIM/Akonadi/Release_Howto|Akonadi Release Howto]]
* [[Projects/PIM/Akonadi/Firstrun|Akonadi Firstrun]]
* Tutorials:
** [[Development/Tutorials/Akonadi/Application|Application Development]]
** [[Development/Tutorials/Akonadi/Resources|Resource Development]]
** [[Development/Tutorials/Akonadi/SerializerPlugin|Serializer Plugin Development]]
** [[Development/Tutorials/Akonadi/CreatingAccountWizardPackages|Creating accountwizard packages]]
* [[Projects/PIM/Akonadi/Bookmarks|Bookmark support based on Akonadi]]
* [http://pim.kde.org/akonadi/ http://pim.kde.org/akonadi/]
* API docs
** [http://api.kde.org/4.x-api/kdepimlibs-apidocs/akonadi/html/index.html Client library]
** [http://api.kde.org/kdesupport-api/kdesupport-apidocs/akonadi/html/ Server]
* #akonadi IRC channel on freenode
* Meetings
** [[Projects/PIM/Akonadi/Meeting2008-11|Halloween Sprint 2008]]
** [http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_7 Osnabrueck 7]
** [[Projects/PIM/Akonadi/Meeting2009-04|Akonadi April Sprint 2009]]
** [[Projects/PIM/Meetings/GCDS_2009|GCDS/aKademy 2009]]
** [[Projects/PIM/Akonadi/Meeting2009-10|Akonadi October Sprint 2009]]
** [http://community.kde.org/KDE_PIM/Meetings/Osnabrueck_8 Osnabrueck 8]
** [http://community.kde.org/KDE_PIM/Meetings/Akonadi-2010-05 Akonadi/KDE PIM pre45 sprint 2010]
* [[Projects/Summer of Code/2009/Ideas#KDE_PIM|Google Summer of Code 2009 Ideas]]
* [[Projects/PIM/Akonadi/PortingStatus|Akonadi Port - List of Bugs and Features]]

Schedules/KDE4/4.5 Release Schedule

2010-04-09T19:32:21Z

Toma: Make it final and add soft/hard api freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: Soft API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API should now be mostly fixed. Changing API is allowed, but commits have to be cc'ed to the kde-bindings mailinglist. This is including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 4th: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Hard API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 6th: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 7th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:44:41Z

Toma: /* June 2nd: Tag Beta 2 */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 4th: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 6th: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 7th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:39:54Z

Toma: /* July 13nd: Tagging freeze */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 6th: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 7th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:39:41Z

Toma: /* July 14th: Tag + release RC 2 */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 7th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:38:23Z

Toma: /* June 23rd: Tag + release RC 1 */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged from the branch. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:37:56Z

Toma: /* June 23rd: Tag + release RC 1 */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===

The 4.5 branch is made and trunk is re-opened for development targetting the 4.6 release. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-29T21:35:54Z

Toma:

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.6 Release Schedule

2010-03-27T23:14:41Z

Toma:

Proposed changes:
* beta 1 time between tag + release is there for sorting out dependencies, since we have a dep freeze, we can do a tag+release at same day for beta2. or <MoDaX> toma: imho, ideally: beta 1 - one week, beta 2 - 3 days, rc1 - 3 days, other RCs - same day
* put some dependencies on cdash?

Schedules/KDE4/4.6 Release Schedule

2010-03-27T23:13:35Z

Toma: Created page with 'Proposed changes: * beta 1 time between tag + release is there for sorting out dependencies, since we have a dep freeze, we can do a tag+release at same day for beta2. * put some...'

Proposed changes:
* beta 1 time between tag + release is there for sorting out dependencies, since we have a dep freeze, we can do a tag+release at same day for beta2.
* put some dependencies on cdash?

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:57:44Z

Toma: /* June 13nd: Tagging freeze */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:56:47Z

Toma: /* June 23rd: Hard Message Freeze */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:56:26Z

Toma: /* June 22rd: Artwork and Bindings Freeze */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22nd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:56:00Z

Toma: /* June 23rd: Artwork and Bindings Freeze */

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 22rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:50:37Z

Toma: Add API Freeze

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed.

=== May 11th: API Freeze ===
To allow the bindings people to have proper time to do there work in preparation to the final release, the API is now frozen. No more changes to APIs or header files (except docs) after this date, including older APIs and newly introduced libraries/APIs.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T22:46:02Z

Toma: Per request tsdgeos

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T19:14:59Z

Toma: Protected "Schedules/KDE4/4.5 Release Schedule" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:21:52Z

Toma:

**** THIS SCHEDULE IS NOT FINAL *******

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:21:18Z

Toma:

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:20:18Z

Toma: /* April 26th: Soft Feature Freeze */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Dependency Freeze ===
From this moment on it is not allowed to add new dependencies or bump dependencies versions. It is possible to get an exception for this. Post the patch to reviewboard and add the release-team as reviewer. We will check if the dependency is needed and is available on all platforms.

In other words: If you have a feature that requires a new dependency or a version of a dependency that is higher than currently checked for in the build system, you need to have committed this change before this date.

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:15:47Z

Toma: /* KDE SC 4.5 */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:15:08Z

Toma: /* July 14th: Tag + release RC 2 */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== June 13nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:14:39Z

Toma: /* June 23rd: Tag + release RC 1 */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 22nd: Tagging freeze ===
During tagging freeze only compilation fixes for all platforms are allowed to be committed. Everything else (even showstopper fixes) *have* to be run through reviewboard, with the release-team and the effected maintainers as reviewer.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:11:23Z

Toma: /* May 19th: Soft Message Freeze. */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until Beta2 is released but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:11:00Z

Toma: /* June 9th: Release Beta 2 */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.
May 19th: Soft Message Freeze.

=== June 9th: Hard Message Freeze ===
Up to now you were able to do typo changes, but you had to mail kde-i18n-doc saying you made a typo fix change. From this moment on you need an explicit ok *forehand* from kde-i18n-doc for every single string change.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:08:19Z

Toma: /* May 19th: Message Freeze. */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Soft Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:07:01Z

Toma: /* May 18th: Hard Feature Freeze */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 11th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:06:04Z

Toma: /* June 23rd: Tag + release RC 1 */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 18th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.5. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:05:41Z

Toma: /* April 26th, 2010: Soft Feature Freeze */

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 18th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Schedules/KDE4/4.5 Release Schedule

2010-03-27T15:05:19Z

Toma: First draft

Planned changes to the schedule:
* put a week between hard feature freeze and beta 1 tagging
* allow spelling changes during message freeze
* soft message freeze at beta1 time, during soft, ccmail on commit, bugfixes only
* hard message freeze at beta2 time, explicit exception at forehand required before commit.
* tagging freeze if r-t is responsive enough.
* dependency freeze at time of the soft feature freeze. big features with new dependencies need to go in before that freeze.

KDE SC 4.5 is a feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for this release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.5 ==

=== April 26th, 2010: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.5_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.6.

=== May 18th: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== May 19th: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== May 19th: Tag Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== May 26th: Release Beta 1 ===
Beta 1 becomes available for general consumption.

=== June 2nd: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== June 2nd: Tag Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== June 9th: Release Beta 2 ===
Beta 2 becomes available for general consumption.

=== June 23rd: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== June 23rd: Tag + release RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed. As soon as the RC has been confirmed to build it will be released immediately.

=== July 14th: Tag + release RC 2 ===
RC 2 release is tagged. As soon as the RC has been confirmed to build it will be released immediately.

=== July 28th: Tag KDE SC 4.5 ===
Branch is frozen for KDE SC 4.5 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== August 4th: Release KDE SC 4.5 ===
KDE SC 4.5 becomes available for general consumption.

Projects/Release Team

2010-02-17T15:57:36Z

Toma: /* Coordinator List */

= The KDE Release Team Project Page =

== Purpose ==
The purpose of the KDE Release Team is to define and execute the official software releases of KDE.

The Release Team is responsible for setting release schedules for the official KDE releases. This includes release dates, deadlines for individual release steps and restrictions for code changes.

The Release Team coordinates release dates with the marketing and press efforts of KDE.

== Members ==
The Release Team is composed of Module Coordinators, Marketing Team liaison (sebas), and the people who actually do the work of tagging and creating the releases (dirk).

As is our tradition, decision making is an open and public process and we welcome input from all concerned parties, including our partners, the packagers, and the distros.

== Contact ==
Please contact the Release Team by [mailto:release-team@kde.org email] or join our public [https://mail.kde.org/mailman/listinfo/release-team mailing list]. The release-team mailinglist is moderated by Richard Moore (IRC: richmoore) and Dirk Müller (IRC: dirk). They will (need to) approve email sent by people not subscribed. In case they miss something (which can always happen as we're all busy people), please ping them on IRC.

== Activities ==
* Make sure KDE is in a releasable state when we release it (this depends of course on the individual modules)
* Plan and communicate when KDE releases happen, and intermediate steps to get there (betas, rcs, code freeze and unfreezes)
* Providing packagers with sufficient information to package and ship KDE (information about dependencies, for example)
* Decide on exemptions for the code freezes (often boils down to granting it if the translation team OKs it)
* Collecting the set of features for the next release
* Take the final decision if a feature enters the release, or not

== Module Coordinators ==
=== Functions ===
Module coordinators perform the following duties:
* primary point of contact for the Release Team concerning issues with the module
* help determine release schedules
* communicate release schedules with the module developers
* provide feedback from developers to the Release Team
* review new applications for inclusion in the module
* review old, unmaintained applications for removal from the modules and help find new maintainers
* review external dependencies for the module
* help set and review goals for major and feature releases
* help with release preparation (eg. update application version numbers)

=== Coordinator List ===

{| border="1"
|-
! Module !! Description !! Release Coordinator
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdelibs kdelibs] || KDE foundational libraries || help wanted
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdepimlibs kdepimlibs] || KDE personal information libraries || [mailto:winter@kde.org Allen Winter]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdebase/runtime kdebase-runtime] ||Applications required by KDE apps to function properly at runtime, such as a help browser, framework (e.g. phonon, solid) backends, and certain configuration modules || [mailto:ogoffart@kde.org Olivier Goffart]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdebase/workspace kdebase-workspace] || the UNIX/Linux desktop shell || [mailto:aseigo@kde.org Aaron Seigo]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdebase/apps kdebase-apps] || Essential apps needed to complement a desktop shell for basic functionality (web browser, file manager, ...) || help wanted
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeaccessibility kdeaccessibility] || Accessibility applications || [mailto:gunnar@schmi-dt.de Gunnar Schmi Dt]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeartwork kdeartwork] || Additional icons, styles, etc. || [mailto:riccardo@kde.org Riccardo Iaconelli]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeadmin kdeadmin] || Tools for system administration || [mailto:nicolas.ternisien@gmail.com Nicolas Ternisien]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeedu kdeedu] || Applications with educational content ||[mailto:annma@kde.org Anne-Marie Mahfouf]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdegames kdegames] || Entertainment || [mailto:matt@milliams.com Matt Williams]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdegraphics kdegraphics] || Graphics viewing and editing || [mailto:aseigo@kde.org Aaron Seigo]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdemultimedia kdemultimedia] || Audio and video applications || [mailto:kretz@kde.org Matthias Kretz]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdenetwork kdenetwork] || Network-centric apps (IM, remote desktop, etc) || [mailto:uwolfer@kde.org Urs Wolfer]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdepim kdepim] || Groupware || [mailto:winter@kde.org Allen Winter]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeplasma-addons kdeplasma-addons] || Plasma applets || [mailto:aseigo@kde.org Aaron Seigo]
|- valign=top
| [http://websvn.kde.org/trunk/kdereview kdereview] || Staging area ||
[mailto:aseigo@kde.org Aaron Seigo]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdesdk kdesdk] || Tools for software development || [mailto:mattr@kde.org Matt Rogers]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdetoys kdetoys] || Fun distractions || [mailto:kde@hilefoks.org Stefan Böhmann]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeutils kdeutils] || Miscellaneous utilities || [mailto:kossebau@kde.org Friedrich W. H. Kossebau]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdevplatform kdevplatform] || KDE Development Applications Platform libraries || [mailto:apaku@gmx.de Andreas Pakulat]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdevelop kdevelop] || KDE IDE || [mailto:apaku@gmx.de Andreas Pakulat]
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdewebdev kdewebdev] || Web development tool suite || [mailto:amantia@kde.org Andras Mantia]
|- valign=top
| [http://websvn.kde.org/trunk/extragear extragear] || Extragear || [mailto:helio@kde.org Helio Chissini de Castro]
|- valign=top
| [http://websvn.kde.org/trunk/l10n-kde4 l10n-kde4] || Localization || [mailto:aacid@kde.org Albert Astals Cid]
|- valign=top
| [http://websvn.kde.org/trunk/koffice koffice] || KOffice || [mailto:cberger@cberger.net Cyrille Berger]
|}

Schedules/KDE4/4.4 Release Schedule

2010-01-26T17:28:41Z

Toma: Add an RC3

KDE SC 4.4 is the fourth feature release for KDE SC 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE SC 4.4 ==

=== October 10th, 2009: Trunk depends on Qt 4.6 ===
Trunk is open for all commits which depend on Qt 4.6. From now on compilation with Qt4.5 will fail.

=== November 4th, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE SC 4.5.

=== November 25th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 25th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways). Exception: Typo fixes can be fixed until RC1 but you have to mail kde-i18n-doc saying you made a typo fix change.

=== November 25th, 2009: Tag KDE SC 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== December 1st, 2009: Release KDE SC 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== December 1st, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 16th, 2009: Tag KDE SC 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 22nd, 2009: Release KDE SC 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== January 5th, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== January 5th, 2010: Tag KDE SC 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2010: Release KDE SC 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 19th, 2010: Tag KDE SC 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 20th, 2010: Release KDE SC 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 28th, 2010: Tag KDE SC 4.4 RC 3 ===
RC 3 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 29th, 2010: Release KDE SC 4.4 RC 3 ===
RC 3 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== February 3rd, 2010: Tag KDE SC 4.4 ===
Branch is frozen for KDE SC 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== February 9th, 2010: Release KDE SC 4.4 ===
KDE SC 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-11-24T13:02:58Z

Toma:

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

All deadlines are due 23:59 UTC, but if you need a few more hours, notify someone from the release team.

== KDE 4.4 ==

=== October 10th, 2009: Trunk depends on Qt 4.6 ===
Trunk is open for all commits which depend on Qt 4.6. From now on compilation with Qt4.5 will fail.

=== November 4th, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed after this date. The feature list also closes today.

Features not already finished or not listed on the planned features page will have to wait until KDE 4.5.

=== November 25th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 25th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 25th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== December 1st, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== December 1st, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 16th, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 22nd, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== January 5th, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== January 5th, 2010: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2010: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 19th, 2010: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 20th, 2010: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== February 3rd, 2010: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== February 9th, 2010: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-09-27T20:02:30Z

Toma: Shift 2 weeks

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

== KDE 4.4 ==

=== October 10th, 2009: Trunk depends on Qt 4.6 ===
Trunk is open for all commits which depend on Qt 4.6. From now on compilation with Qt4.5 will fail.

=== November 4th, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed. The feature list also closes today.

Features not already finished or listed on the planned features page will have to wait until KDE 4.5.

=== November 25th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 25th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 25th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== December 1st, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== December 1st, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 16nd, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 22nd, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== January 5th, 2010: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== January 5th, 2010: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2010: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 19th, 2010: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 20th, 2010: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== February 3rd, 2010: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== February 9th, 2010: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-08-30T16:03:31Z

Toma: Make it final

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

== KDE 4.4 ==

=== October 21st, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed. The feature list also closes today.

Features not already finished or listed on the planned features page will have to wait until KDE 4.5.

=== November 11th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 11th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 11th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== November 17th, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== November 26th, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 2nd, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 8th, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== December 22nd, 2009: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== December 22nd, 2009: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 23th, 2009: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 5th, 2010: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2010: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== January 20th, 2010: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== January 26th, 2010: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-08-26T21:40:18Z

Toma: Protected "Schedules/KDE4/4.4 Release Schedule" ([edit=autoconfirmed] (indefinite) [move=autoconfirmed] (indefinite))

This schedule will change and is discussed at this moment on the release-team mailinglist.

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

== KDE 4.4 ==

=== October 21st, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed. The feature list also closes today.

Features not already finished or listed on the planned features page will have to wait until KDE 4.5.

=== November 11th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 11th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 11th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== November 17th, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== November 26th, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 2nd, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 8th, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== December 22nd, 2009: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== December 22nd, 2009: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.4. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 23th, 2009: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 5th, 2009: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.4 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2009: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== January 20th, 2009: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== January 26th, 2009: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-08-26T20:11:10Z

Toma:

Schedules/KDE4/4.4 Release Schedule

2009-08-26T20:04:52Z

Toma:

This schedule will change and is discussed at this moment on the release-team mailinglist.

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

== KDE 4.4 ==

=== October 21st, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed. The feature list also closes today.

Features not already finished or listed on the planned features page will have to wait until KDE 4.5.

=== November 4th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 4th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 4th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== November 10th, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== November 26th, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 2nd, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 8th, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== December 22nd, 2009: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== December 22nd, 2009: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.3. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 23th, 2009: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 5th, 2009: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.3 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2009: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== January 20th, 2009: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== January 26th, 2009: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.4 Release Schedule

2009-08-26T20:01:40Z

Toma: Try to make a schedule.

This schedule will change and is discussed at this moment on the release-team mailinglist.

KDE 4.4 is the fourth feature release for KDE 4. All dates given here are subject to revision, but we will try our best to stick to them if possible. The KDE Release Team is acting as the coordinator for the 4.4 release.

== KDE 4.4 ==

=== October 21st, 2009: Soft Feature Freeze ===
Trunk is frozen for feature commits that are not listed in the [[Schedules/KDE4/4.4_Feature_Plan | planned feature document]]. Only bugfixes and the code implementing the listed features are to be committed. The feature list also closes today.

Features not already finished or listed on the planned features page will have to wait until KDE 4.5.

=== November 4th, 2009: Hard Feature Freeze ===
Trunk is frozen for all feature commits, even those listed in the planned feature document. Only bug fixes are allowed. Binary compatibility for new API is not yet required.

=== November 4th, 2009: Message Freeze. ===
All translated messages (GUI strings) are frozen on this date. Only previously untranslated strings or clear errors in strings can be fixed. No major new strings changes should be done. It is ok to remove strings. Exception: Artwork (try to keep the number of new strings low anyways).

=== November 4th, 2009: Tag KDE 4.4 Beta 1 ===
Trunk is frozen for Beta 1 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed. The usual beta rules apply as soon as the Beta tarballs have been generated.

=== November 10th, 2009: Release KDE 4.4 Beta 1 ===
Beta 1 becomes available for general consumption.

=== November 26th, 2009: Documentation/Handbook Freeze ===
No more substantive changes to documentation or handbooks after this date. Typos, spelling and simple grammar changes are permitted.

=== December 2nd, 2009: Tag KDE 4.4 Beta 2 ===
Trunk is frozen for Beta 2 release tagging. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 8th, 2009: Release KDE 4.4 Beta 2 ===
Beta 2 becomes available for general consumption.

=== December 23rd, 2009: Artwork and Bindings Freeze ===
All artwork is frozen on this date. No new artwork should be added. Existing artwork can continue to be tweaked and fixed.

No new additions to the language bindings, except optional bindings as permitting by the kde-bindings team.

=== December 23rd, 2009: Tag KDE 4.4 RC 1 ===
Trunk is frozen for branching into branches/KDE/4.3. Afterwards, RC 1 release is tagged. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== December 23th, 2009: Release KDE 4.4 RC 1 ===
RC 1 becomes available for general consumption. Incoming bugs will be reviewed for their severity.

=== January 5th, 2009: Tag KDE 4.4 RC 2 ===
RC 2 is tagged from branches/KDE/4.3 and source tarballs are built. Only urgent fixes, such as those fixing compilation errors, should be committed.

=== January 6th, 2009: Release KDE 4.4 RC 2 ===
RC 2 becomes available for general consumption. Incoming bugs will be reviewed for their severity. Additional release candidates will be created as needed with a 2 weeks interval

=== January 20th, 2009: Tag KDE 4.4 ===
Branch is frozen for KDE 4.4 tagging. Only very urgent fixes, such as those fixing compilation errors, should be committed.

=== January 26th, 2009: Release KDE 4.4 ===
KDE 4.4 becomes available for general consumption.

Schedules/KDE4/4.0 Module Status

2009-07-23T21:35:30Z

Toma: i'm no longer maintaining kdereview

This page is used by the KDE4 Release Team to keep track of the current state of the KDE4 release process.

== Moving / Removing Applications ==

Here is a quick checklist for moving or removing an application:

=== Documentation ===

Documentation for each application is kept in the {{path|doc/}} folder in the top level of the module. Be sure to move or remove the associated documentation when you move or remove an application.

=== i18n ===
When moving or removing applications from a module, be sure to move or remove the relevant pot files for the application in the {{path|/trunk/l10n-kde4/templates/messages}}
and {{path|/trunk/l10n-kde4/templates/docmessages}} folders. Then make sure you add entries to {{path|/trunk/l10n-kde4/scripts/process_orphans.txt}} that note what was done.

There is no need to checkout everything from l10n-kde4, just the {{path|templates}} and {{path|scripts}} folders.

=== Build System ===

Remember to edit all the relevant CMakeLists.txt files in both the origin and destination modules when moving an application.

== Module Status ==

{| border="1"
|-
! Module !! Description !! Release Coordinator !! Status
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdelibs kdelibs] || KDE foundational libraries || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdepimlibs kdepimlibs] || KDE personal information libraries || [mailto:winter@kde.org Allen Winter] ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdebase kdebase] || Runtime, workspace and essential apps || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeaccessibility kdeaccessibility] || Accessibility applications || [mailto:gunnar@schmi-dt.de Gunnar Schmi Dt] ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeartwork kdeartwork] || Additional icons, styles, etc. || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeadmin kdeadmin] || Tools for system administration || [mailto:nicolas.ternisien@gmail.com Nicolas Ternisien] ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeedu kdeedu] || Applications with educational content ||[mailto:annma@kde.org Anne-Marie Mahfouf] || Most applications ported
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdegames kdegames] || Entertainment || [mailto:johann.ollivierlapeyre@gmail.com Johann Ollivier-Lapeyre] ||100% compile, unmaintained and too-low quality games removed.
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdegraphics kdegraphics] || Graphics viewing and editing || [mailto:aseigo@kde.org Aaron Seigo] || Various states of development, generally working however
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdemultimedia kdemultimedia] || Audio and video applications || [mailto:kretz@kde.org Matthias Kretz] || much code to move out or port/finish porting
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdenetwork kdenetwork] || Network-centric apps (IM, remote desktop, etc) || [mailto:uwolfer@kde.org Urs Wolfer] || not fully ported, needs lots of work
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdepim kdepim] || Groupware || [mailto:winter@kde.org Allen Winter] || not fully ported, needs lots of work
|- valign=top
| [http://websvn.kde.org/trunk/kdereview kdereview] || Staging area || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdesdk kdesdk] || Tools for software development || [mailto:mattr@kde.org Matt Rogers] ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdetoys kdetoys] || Fun distractions || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdeutils kdeutils] || Miscellaneous utilities || ||
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdevelop kdevelop] || IDE || [mailto:mattr@kde.org Matt Rogers] || Ported. In development.
|- valign=top
| [http://websvn.kde.org/trunk/KDE/kdewebdev kdewebdev] || Web development tool suite || [mailto:amantia@kde.org Andras Mantia]|| Partly ported, needs lot of work.
|- valign=top
| [http://websvn.kde.org/trunk/extragear extragear] || Extragear || [mailto:helio@kde.org Helio Chissini de Castro] ||
|- valign=top
| [http://websvn.kde.org/trunk/l10n-kde4 l10n-kde4] || Localization || [mailto:aacid@kde.org Albert Astals Cid] ||
|}

== Pending Application Issues ==

*'''Green''': discussed and approved
*'''Orange''': discussed, but pending on or blocked by other issues
*'''Red''': no progress made at this point

=== kdeedu ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| Marble || Move into module after being ported to KDE || Torsten Rahn || Torsten Rahn || Move completed
|- style="background-color: lightgreen;"
| KAlgebra || Move into module after being ported to KDE || Aleix Pol || Aleix Pol || Move completed
|- style="background-color: lightgreen;"
| KLatin || Move to blackhole || kdeedu devels || unmaintained || Black hole
|}

=== kdegames ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| KSquares || Move into module || Matt Williams || Matt Williams || Move Complete
|- style="background-color: lightgreen;"
| Kiriki || Move into module || Albert Astals Cid || Albert Astals Cid || Move Complete
|- style="background-color: lightgreen;"
| atlantik / atlantikdesigner || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kfouleggs || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kbackgammon || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| klickety || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kpoker || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kenolaba || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kasteroids || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ksnake || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ksokoban || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| ktron || Remove from module || KDE Games Team || KDE Games Team || Move Complete
|- style="background-color: lightgreen;"
| kwin4 || Rename || KDE Games Team || KDE Games Team || Renamed to KFourInLine
|}
[http://techbase.kde.org/Projects/Games/Status_KDE_4.0 Detailed Status of application kept in module for the 4.0 release]

=== kdegraphics ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| KGhostview || Move to unmaintained/4. Functionality will be performed by okular || Aaron Seigo || Luís Pedro Coelho || Move complete
|- style="background-color: lightgreen;"
| KFax || Move to extragear pending G3/G4 raw TIFF file support in Okular || Aaron Seigo || || Move complete
|}

=== kdemultimedia ===
{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen"
| kaboodle || port to KDE4/Phonon or replace || Matthias Kretz || - || removed
|- style="background-color: lightgreen"
| noatun || Determine if ready for KDE 4.0 and whether it should stay in kdemultimedia || Matthias Kretz || Charles Samuels/Stefan Gehn || RIP
|- style="background-color: lightgreen"
| phonon-gst/gst2/nmm || Determine if ready for KDE 4.0 and whether it should stay in kdemultimedia || Matthias Kretz || Matthias Kretz || moved to playground
|}

=== kdenetwork ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| KNewsTicker || Determine if still needed with Plasma || Urs Wolfer || Frerich Raabe || Ported to Plasma
|- style="background-color: lightgreen;"
| KWiFiManager || Remove. Solid based solution, NetworkManager from kdebase || Urs Wolfer || Stefan Winter || Done
|- style="background-color: lightgreen;"
| KDict || Remove. || Urs Wolfer || - || Done
|- style="background-color: lightgreen;"
| KGet|| Move back to module from branch || KGet Team || [mailto:kget@kde.org KGet Team] || Done
|}

=== kdepim ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| Kabcclient || Move into module || Kevin Krammer || Kevin Krammer || Approved and ported. Needs a handbook, apidox, and cleanup
|- style="background-color: lightgreen;"
| kmobiletools || Move into module || Marco Gulino || Marco Gulino || Move complete.
|- style="background-color: lightgreen;"
| kpilot || Resurrect || Adriaan de Groot || Adriaan de Groot || Move complete.
|- style="background-color: lightgreen;"
| kandy || Remove from module || PIM team || PIM team || Approved and removed.
|- style="background-color: lightgreen;"
| kmobile || Remove from module || PIM team || PIM team || Approved and removed.
|}

=== kdesdk ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: #ffc642;"
| Kaider || Move into module, replace KBabel || Nick Shaforostoff || Nick Shaforostoff || In extragear; till KDE 4.1
|- style="background-color: lightgreen"
| KBabel || Remove || Nick Shaforostoff || Nick Shaforostoff || in favor of KAider
|}

=== kdeutils ===

{| border="1"
|-
! Application !! Request !! Request By !! App Contact !! Status
|- style="background-color: lightgreen;"
| KRegexpEditor || Doesn't work. No Maintainer. Move to playground || Matt Rodgers || Matt Rodgers || in playground; till 4.1
|- style="background-color: lightgreen;"
| KHexEdit || Move to unmaintained/4. Port to KDE4 not fully completed, no Maintainer. Okteta might replace in 4.1|| Friedrich Kossebau || Friedrich Kossebau || Move complete
|}

Policies/Commit Policy

2009-06-26T21:43:40Z

Toma: /* Special keywords in SVN log messages */

== Guidelines ==
=== Think Twice before Committing ===
Committing something to SVN has serious consequences. All other developers will get your changes once they are in SVN, and if they break something, they will break it for everybody. All commits will be publicly available in the SVN repository forever.

On the other hand SVN allows one to revert changes, so it's possible to recover from mistakes. This is relatively easy for commits to single files but it can also be a significant amount of work for bigger changes.
The baseline is: Be aware of the consequences of your commits. Take time to think about them before committing.

=== Never commit code that doesn't compile ===
Compile the code and correct all errors before committing. Make sure that newly added files are committed. If they are missing your local compile will work fine but everybody else won't be able to compile.

You certainly should make sure that the code compiles with your local setup. You should also consider what consequences your commit will have for compiling with the source directory being different from the build directory. It would also be nice if it would compile with the <tt>--enable-final</tt> option, but we don't explicitly support that.

Be especially careful if you change the build system, i.e. Makefiles

=== Test your changes before committing ===
Start the application affected by your change and make sure that the changed code behaves as desired.

Run unit and regression tests, if available (KDE4: <tt>make test</tt>, KDE3: <tt>make check</tt>).

=== Double check what you commit ===
Do a <tt>svn update</tt> and a <tt>svn diff</tt> before committing. Take messages from SVN about conflicts, unknown files, etc. seriously. ''svn diff'' will tell you exactly what you will be committing. Check if that's really what you intended to commit.

=== Always add descriptive log messages ===
Log messages should be understandable to someone who sees only the log. They shouldn't depend on information outside the context of the commit. Try to put the log messages only to those files which are really affected by the change described in the log message.

In particular put all important information which can't be seen from the diff in the log message.

=== Honor KDE coding policies ===
This includes security (shell quoting, buffer overflows, format string vulnerabilities), binary compatibility (d pointers), i18n, usability, user interface style guide, (API) documentation, documentation and definition of memory management and ownership policies, method naming, conditions for inclusion in kdelibs, portability issues and license notices.

These policies are defined separately. If in doubt ask on the mailing list.

=== Respect commit policies set by the Release Plans ===

=== Respect other developer's code ===
Respect the policies of application and library maintainers, and consult with them before making large changes.

Source control systems are not a substitute for developer communication.

=== Announce changes in advance ===
When you plan to make changes which affect a lot of different code in SVN, announce them on the mailing list in advance. For instance, changes in libraries might break other code even if they look trivial, e.g., because an application must also compile with older versions of the library for some reasons. By announcing the changes in advance, developers are prepared, and can express concerns before something gets broken.

=== Code review by other developers ===
Don't commit changes to the public API of libraries without prior review by other developers. There are certain special requirements for the public APIs of the KDE libraries, e.g., source and binary compatibility issues. Changes to the public APIs affect many other KDE developers including third party developers, so requiring a review for these changes is intended to avoid problems for the users of the APIs and to improve the quality of the APIs.

=== Take responsibility for your commits ===
If your commit breaks something or has side effects on other code, take the responsibility to fix or help fix the problems.

=== Don't commit code you don't understand ===
Avoid things like "I don't know why it crashes, but when I do this, it does not crash anymore." or "I'm not completely sure if that's right, but at least it works for me.".

If you don't find a solution to a problem, discuss it with other developers.

=== Don't commit if other developers disagree ===
If there are disagreements over code changes, these should be resolved by discussing them on the mailing lists or in private, not by forcing code on others by simply committing the changes to SVN.

=== Backport bugfixes ===
If you commit bugfixes, consider porting the fixes to other branches. Use the same comment for both the original fix and the backport, that way it is easy to see which fixes have been backported already.

=== Use bug tracking system numbers ===
If you fix bugs reported on the bug tracking system, add the bug number to the log message. In order to keep the bug tracking system in sync with SVN, you should reference the bug report in your commits, and close the fixed bugs in the bug tracking system.

This doesn't mean that you don't need an understandable log message. It should be clear from the log message what has been changed without looking at the bug report.

=== Tags and branches ===
There are rules for where to place release tags and branches in the repository. Official KDE branches and release will be created by the release KDE coordinator in the {{path|branches/KDE}} and {{path|tags/KDE}} directories, scripts will ensure that this folders are protected.

Developers should place all branches which are aimed to be released in {{path|branches/appname}} and name them like the release, e.g. {{path|branches/appname/1.5}}. For all release tags, {{path|tags/appname}} is the right place.

All temporary working branches (which should be deleted again after the work has ended) should be located in {{path|branches/work}} with some name describing both which part of KDE (or which application) is branched and which work is done there. A good example would be {{path|branches/work/khtml-paged}} for a khtml working branch to include paged media support. Bad idea would be something like {{path|branches/work/make-it-cool}}.

=== Don't add generated files to the repository ===
Files generated at build time shouldn't be checked into the repository because this is redundant information and might cause conflicts. Only real source files should be in SVN. An exception to that are files generated by tools that would be an unusual requirement for building KDE.

Standard tools include gcc, g++, cmake, /bin/sh, perl, moc, uic and the tools part of KDE itself. Tools needed for KDE applications written in non-C++ are allowed as well (e.g. python, ruby).

Tools which shouldn't be a requirement for building KDE include lex/flex, yacc/bison, python, ruby etc.

=== Don't use SVN keywords in source files ===
SVN keywords like <tt>Id</tt> or <tt>Log</tt> cause unnecessary conflicts when merging branches and don't contain any information which wouldn't be available in the SVN repository anyway.

=== Commit complete changesets ===
SVN has the ability to commit more than one file at a time. Therefore, please commit all related changes in multiple files, even if they span over multiple directories at the same time in the same commit. This way, you ensure that SVN stays in a compileable state before and after the commit, that the commit history (svn log) is more helpful and that the kde-commits mailing list is not flooded with useless mails.

OTOH, commits should be preferably "atomic" - not splittable. That means that every bugfix, feature, refactoring or reformatting should go into an own commit. This, too, improves the readability of the history. Additionally, it makes porting changes between branches (cherry-picking) and finding faulty commits (by bisecting) simpler.
While most KDE developers do not pay much attention to that rule, some do so very much. Consequently, you should be very careful about it when making commits in areas which you do not maintain.

=== Don't mix formatting changes with code changes ===
Changing formatting like indenting or white spaces blows up the diff, so that it is hard to find code changes if they are mixed with re-indenting commits or similar things when looking at the logs and diffs later. Committing formatting changes separately solves this problem.

=== GUI Changes ===
If your commit causes user visible GUI changes, add the <tt>GUI</tt> keyword to the log message. This makes sure that the documentation writers get notified of your changes.

== Special keywords in SVN log messages ==
When you commit changes to SVN you will be asked for a description of your commit. There are several special keywords defined that you can use in this description. These keywords are always uppercase.

The following keywords are pseudo-headers - they have to appear at the start of a line and be followed by a colon:
* '''FEATURE:''' [''<bugnumber>''] Marks the feature as implemented by CC'ing the commit message to <bugnumber>-done@bugs.kde.org. This keyword will also be used to automatically extract entries for the release changelog, so it makes sense to use it for new features even if you don't have a bugnumber for the feature.
* '''BUG:''' ''<bugnumber>'' Marks the bug as fixed by CC'ing the commit message to <bugnumber>-done@bugs.kde.org. This keyword will also be used to automatically extract entries for the release changelog.
* '''CCBUG:''' ''<bugnumber>'' CC's to the bugreport by sending mail to <bugnumber>@bugs.kde.org
* '''CCMAIL:''' <email-address> CC's to the given e-mail address.
* '''GUI:''' Indicates a user visible change in the user interface. This is used to make the documentation team aware of such changes.

This keyword can appear anywhere on a line:
* '''SVN_SILENT''' Marks the commit message "silent" by adding "(silent)" to the subject of the mail to allow filtering out trivial commits. Use this tag carefully and only for really uninteresting, uncontroversial commits.

* '''SVN_MERGE''' Special keyword for people that use the svnmerge script. Marks the commit message as being a merge commit by adding "(merge)" to the subject of the mail. This way receivers can filter out mails that are caused by merging the same patch from one branch to another branch. Reviews of those mails is usually not needed. This keyword filters out the endless property changes used by this script.

== Contact ==
This page is maintained by [mailto:schumacher@kde.org Cornelius Schumacher].

[[Category:Policies]]