I blogged earlier about KDE potentially moving our repositories from the ancient and archaic CVS system to the new hotness known as Subversion.
This time around, I've got more ammunition for discussion and a lot of thoughts about the relative strengths and weaknesses of each system as they apply to KDE. Hopefully other KDE developers will read these notes and at least take them into consideration when discussing our eventual move away from CVS.
So - first off, a few words about CVS. CVS has served KDE faithfully for years, and has been (for us) fairly stable and reliable. It doesn't change much. And, believe it or not, CVS does have some strengths.
|- Ubiquitous (practically every operating system on every platform can run CVS) - Relatively light on resource usage - Comparitively light on disk usage - It actually **works**||- Branching is painful - Lacking in certain very basic features - Lack of atomicity with commits; no transactions - Not very well-optimized for low-bandwidth - Difficulty handling binary files properly|
|- Little to no learning curve if you already know CVS - Atomic commits, with transactions - File renames - More efficient wire protocol for low-bandwidth||- Disk usage is significantly higher than CVS for a converted repository - Subversion seems slower than CVS, quite a bit so in some cases - Not nearly as ubiquitous as CVS (yet) - Resource usage is relatively higher than CVS|
|- Super intelligent merging support - GPG signing support - Seamless inter-archive branching support - Very easy on server-side resources - Offline commits||- Relatively high learning curve - Nowhere near as ubiquitous as even Subversion - Rather difficult and verbose user-interface - Disk usage is also higher than CVS - Speed is not very impressive|
I think that Subversion is a much more natural fit for KDE than Arch. We have a very centralized development model; however, the disk usage issue is depressing to think about. I ran a test conversion of our kdelibs repository from CVS to Subversion, once using the Berkeley database backend and once using the new fsfs backend; the bdb backend takes up 1194M of space, and the fsfs backend takes 1130M of space on my system. In comparison, the CVS repository takes up 281M of space for the same revisions. Some of the Subversion developers have offered me a few hints, but I cringe to think about how difficult the migration will be for a large module such as kde-i18n.