On 2009-01-30T09:01:47, Adrian Schröter <adrian(a)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. ;-)
_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
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.
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(a)opensuse.org
For additional commands, e-mail: opensuse-packaging+help(a)opensuse.org