On 2009-01-30T09:01:47, Adrian Schröter <adrian@suse.de> wrote:
Look at _link: it's a hack implementing something which could easily be implemented as well (and probably more completely) using chained repos with hg/git (or any other distributed versioning system), which would help trace merges etc.
_link has functionlity (like the complete source server) which allows also features of controling the build counters. It fits into the project/package concept also well. I disagree that it is a hack.
Yes, everything could be also implemented different.
I didn't actually mean "hack" necessarily negatively (I'm old enough to think of hacking as something positive and cracking as the evil sort ;-) But it was a case in point which could have been implemented using chained repos, if that had been available. And which, strangely enough, would have avoiding a couple of other issues, like history or retrieving the full/expanded version of a link'ed project at some specific time (instead of just the present). It just sprang to my mind because it was the nuisance of the day. ;-)
Yes, for _every single feature_, it's easier to add the feature to osc instead of switching to a "known" and complete DVCS. But if you look at the whole picture, I'd bet it doesn't hold. And that would mean that we need to support _every single feature_ regarding our special needs for package building in this DVCS. This is more work and will lead to an inconsistent system.
That I just don't believe. What _are_ the specific needs? Why is osc better at managing the inputs to the build process - which is all I'm asking to suggesting to replace, of course the build process then would need to consume that - than an existing, complete DVCS? Heck, we had issues in the past where osc didn't handle removed files correctly. That is now resolved, but still, it shows that there was a non-zero cost to reinventing a wheel. There's also the problem of storing several local patches. You always have to commit to the server. Or layer a separate SCM (like quilt) over the local working copy. Not to mention usability as in "yet another SCM to learn".
But since we just repeat arguments from the discussion month ago, I will stop here.
As this keeps coming up, maybe your arguments against this could be documented and explained on a wiki page? Then, if the arguments hold, you'll never have to explain it again ;-)
We could invest our time really better by just supporting the merge handling.
Adrian, that's your opinion, and you're of course entitled to it. I still think you are completely wrong for the mid- and definitely the long-term, and possibly experiencing NIH syndrome. Because today, it is merge handling. Tomorrow, someone will want disconnected operation or queuing of patches. Then someone will want to exchange patches with someone else, or merge theirs, without going through the server. Then someone will notice that osc would rock if it had bisect. And how useful it would be if the version control integrated with their editor/IDE. Or had a graphical history browser. Were able to run "annotate" on the specfile. Or exclude merges from the log output. Or filter logs/revisions by dates. How about a web history browser? ... I'll stop there. The point is: all of this and more you'd get for free with an existing SCM. Yes, the non-SCM related commands which drive the build service would still be needed in osc of course, no doubt. That makes sense. Rolling your own SCM is not a rational choice by any means, though. 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-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org