On Wednesday 11 July 2007 19:27:50 Paolo Capriotti wrote:
> Yes, provided you don't publish your repository, because git-svn requires
> you to rebase your local git commits on top of the svn repository, and that
> may break commits done in another git repository.

I just see that we have 2 scenarios:

* 1: Switch svn.kde.org to something else (e.g. git) or run other systems in 
parallel. This increases the work for sysadmin, for script(y) writers and 
especially for casual contributors.

* 2: Keeping SVN centrally and push the additional work for non-SVN systems 
towards those who want it.
If you want to hack on the train or at home without internet connection (and 
that's what I read from aseigo's mail), using SVK is just fine and you simply 
replay all of your changes to SVN once in a while.
If you want a more separate development branch, you can publish your SVK 
mirror for others to use as a repository. It's still using a central model, 
but it doesn't break the commits of others when replaying the commits to 
svn.kde.org.
It's not ideal, and SVK needs 26 non-standard perl modules for not being 
ideal, but it works with the current system and covers the two use cases that 
I just mentioned.

Realistically spoken, we can only have scenario 2.

Josef