So, today almost no xine work, actually almost no work on Open Source at all; I had to relax a bit myself, and I had to continue testing stuff for my job before the contract expires (at the end of the month), but I found time to write to xine-devel again, asking to change version control system, because CVS is driving me nuts.
Why do I think xine needs a better version control system? Well, it’s actually easy to say; read my two previous posts, and you a see that there are a lot of details that I think should be fleshed out and fixed, especially in foresee of xine being default Phonon’s engine.
Some of these, like the memory management thing I thought of, aren’t changes that you’d expect in a stable branch, or even on a «future development» branch, as it can be risky, needs a lot of changes, and is not, in its first stages, targeted to anyone but the developer doing the work; one can develop locally, but that means he loses ability to check its paces without losing history, and also is a mess to merge back into the main branches, as you usually end up doing one big commit with everything.
Branching with CVS sucks, or rather it’s the merging that sucks a lot, something I don’t really want to try if I can avoid it. Subversion improves a bit, but I still think it’s flaky, while the whole distributed VCS series that we get nowadays (GIT and Mercurial first), uses branches as main unit of development, rather than repositories. This is quite cool for this kind of tasks.
In addition to this, non-atomic commits are problematic, and the current workflow is a total mess, as the only really active developers in xine lately have been me and Darren Salt (gxine’s author), with Claudio Ciccani working on xine-plugin. Miguel’s commits result to be slightly less than Darren’s because he checked in a few FFmpeg’s bumps, which caused the commit amount to jump up (non-atomic commits, once again). What we need is an adrenaline injection, simplifying the contribution of patches from users, hoping to find new developers or the project will wither.
Now we’ll see what will be the outcome this time around; sincerely I’m not going to accept the answer I got last time about not being yet the time to change SCM, said by the admins, whom are not committing for months now (I didn’t find even a single commit from Mike on the last six months).
On the other hand, to play locally with importing xine into GIT to see the results, I’ve written a nice script that, when ran on a checkout of a CVS repository on SourceForge.net, will give you the authors file suitable for git-cvsimport use. It page-scrapes SourceForge’s users page to get the real name there given (which might not be perfect for users who didn’t update their name after sf switched to UTF-8), and uses the user (at) users.sourceforge.net mail address, so you might want to change it a bit for instance if you know some users will prefer advertising another address, but it should cover well for those developers you can’t contact anymore (disappeared or passed away even). The page-scraping is done through wget and awk (the awk script is inlined in the sh one), and the script is actually one single command pipe (with a loop and a subshell, okay) to the shell, if written properly it can easily be a oneliner.
It might be useful if someone else is thinking about changing from SF.net’s CVS to GIT…
