Convenience kdesupport tags for building kdelibs-4.1.x

[David Faure]

The release-team has decided to improve the organization of the kdesupport system we use.
Please read the details below.

Problem
------------
KDE development is divided in several branches, especially the current stable KDE branch and the unstable development branch in trunk. kdesupport libraries are independent of KDE, but KDE depends on them. At this moment there is no indication at all which kdesupport library should be used for a certain KDE branch.

We want a simple system for developers to just know for sure that they got the right kdesupport libraries when they want to compile a KDE tree completely from subversion.

In addition, kdesupport developers have indicated that they would like to be able to work in trunk without the constant fear of breaking compilation in some remote module and being yelled at by 500 people :)

Solution
------------
For each main kde tree we will create a tag. For example for the current stable KDE release I just created a tags/kdesupport-for-4.1/kdesupport.
Within that folder there are (cheap) copies of the kdesupport libraries which should be used for compiling the KDE 4.1 tree. For example:
   tags/kdesupport-for-4.1/kdesupport/phonon/    (svn cp'ed from tags/phonon/4.2.0)
   tags/kdesupport-for-4.1/kdesupport/strigi/    (svn cp'ed from tags/strigi/strigi/0.5.11)
   tags/kdesupport-for-4.1/kdesupport/qca/    (svn cp'ed from tags/qca/2.0.1)
It contains a CMakeLists.txt file, so all subdirectories can be built in one go. So if you want KDE-4.1, just simply checkout this tag before compiling kdelibs and you are done. For those using kdesvn-build, it means simply adding this line in the kdesupport module:
  module-base-path tags/kdesupport-for-4.1

The same will go for trunk, so we will create a kdesupport-for-trunk. This also contains copies to the right version of the kdesupport libraries needed to build trunk. That means developers have a choice: either use trunk/kdesupport where development takes place, so that could lead to breakage in for example kdelibs but you can probably fix them, or you choose to compile KDE trunk with kdesupport from /tags/kdesupport-for-trunk and you are sure kdelibs trunk compiles from it.
That's the idea, but in practice I haven't created it yet, because I'm not sure which versions to put in it right now...

Who
------------
The kdesupport maintainers should make sure that the right version if available in each tag. If they release a new version they update the copy with a simple svn rm + svn cp. If some kdesupport developers think everyone should just use their trunk, they could just regularly rm+cp the "tag" from their trunk. An svn external would have been more appropriate in that case, but that's unfortunately not an option for now.

Thanks
------------
To Tom Albers for most of the above writing.

-- 
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).