On Friday 26 September 2008 20:47:10 wrote Lars Marowsky-Bree:
On 2008-09-26T06:58:42, Adrian Schröter <adrian@suse.de> wrote: ...
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. have a nice weekend adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org