But it is pointless to discuss the current source handling, when all
other solutions do not even support the stuff where we have detail
problems. We would only loose and not gain anything, just lots of
additonal work to add lots of functionality on top of it what will cause
for sure new problems.

Better fix the missing 1% instead of rewriting the other 99% ;)

That's easy enough to say after one has rewritten the remaining 90% of
an SCM already - as a mid- to long-term maintenance decision, that isn't
the best choice, and something which we should try and overcome.

The base of our system is several years old (dunno if it was there 11 years
ago already), it has proven to be stable, maintainable and also very
important, performant enough (I doubt svn is, after the problems I have seen
when KDE moved (Mandriva lived with these and they have also not the load
we have on the system, since they have a closed system, where rebuilds need to
triggered manually, so this is also no argument)).

There's really no good point why we need to have our own SCM, whereas
there's a pretty strong point to reuse an existing one, possibly with
extensions - but both git or mercurial _can_ be extended with modules.

You are aware that this modules would be the majority of important code for
us. We have currently ONE interface to request the classic source handling,
dependency calculation, project handling, rights management, build counting
and so on all handled by the source server. It handles also specific sources
differently to avoid otherwise necessary automatic source commits, which
would IMHO a bad design.

We have really a special use case, not matching to the others where svn
and friends are designed for.

When we would start on a move now, we would have end of next year maybe the
same status as now, but no clean, single interface anymore and I fear also a
less secure setup.

And apart from this I think end of next year the next SCM management tool is
cool and the discussion will start again ;)

We'd still gain all the other features - bisect, history browsers,
commands we're used to, etc.

Writing a wrapper from our interface to these clients would be a better
approach here. But it would not help us with the specialitiest we start to
discuss here in this thread.