On 2008-09-26T06:58:42, Adrian Schröter <adrian@suse.de> wrote:
but this is not a system to keep a branch automatically up2date and just storing your changes like the source links does.
Stacked git etc can handle that, or rebasing trees, or the name of the new git extension which was discussed at the Labs Conf and whose name I've currently forgotten ...
There is also no functionality for handling all the functionality like topadd or automatic changelog handling like planned.
Nobody is disagreeing that there might be some things which should be wrapped around as convenience helpers. But I would agree there is a strong point for reusing an existing SCM as a back-end.
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. 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. We'd still gain all the other features - bisect, history browsers, commands we're used to, etc. Regards, Lars -- Teamlead Kernel, SuSE Labs, Research and Development SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) "Experience is the name everyone gives to their mistakes." -- Oscar Wilde -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org