Mailinglist Archive: opensuse-buildservice (284 mails)

< Previous Next >
Re: [opensuse-buildservice] New openSUSE Buildservice Roadmap
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Thu, 25 Oct 2007 15:52:14 +0200
  • Message-id: <20071025135214.GK8131@xxxxxxx>
On Thu, Oct 25, 2007 at 09:27:39AM +0200, Klaas Freitag wrote:
On Thursday 25 October 2007 01:08, Michael Wolf wrote:
On Wed, 2007-17-10 at 10:28 +0200, Michael Schroeder wrote:
On Tue, Oct 16, 2007 at 02:30:47PM -0500, Michael Wolf wrote:
Do the improvements listed at
ion_1.0.29.2C_April_2008 imply distributed revision control? Many
people, myself included, want this very much.

Hmm, this is more a tool issue than something we can do on the
build service. The build service currently stores the sources
pretty much the same way as git does, except that it uses
md5 sums instead of sha1 sums to identify a release (this is
for historical reasons).
I'm thinking about switching it over to sha1 so that it is
compatible to git, but I need to find some spare time for this.

If we could use git (with all of its features, of course) in place of
"osc diff", "osc commit", etc., that might be OK, although it seems like
more work in the long run than just using revision control in the first
I think that's reasonable and would like to have that for the reasons
that we do not have to maintain git ourselves, that people of all
colour continue to ask "do you use a real source control system?" and
we can easily answer 'yes' than and finally that we hopefully benefit
from existing tools that set up on git. Hopefully, because I have nothing
special in mind. Anybody else?

I am sometimes asked, why osc was written in the first place, and why
the existing subversion client was not used. The answer is twofold. 1) A
subversion client is not compatible to our similar but "reduced" api, it
expects a WebDAV server, with extensions even. 2) hacking the massive
codebase of a subversion or even maintaining a branch of it to work with
the BS seems like a big task. But at least 50% of osc code is code that
has nothing to do with version control (and don't fit into svn), and
most of the other 50% (version control specific) are too trivially to

Of course, the non-version control parts *could* be implemented in a
separate tool.

I am sometimes asked, why the BS doesn't offer an api which is
compatible to WebDAV. Well, it was designed ground up, why not, and grew
to a more complex thing later, I personally see the shortcomings but
believe that it would have been more work to use something existing.

As the question goes, whether to switch to some distributed version
control paradigm (whatever its name), I can't see a projected switch as
a pure advantage. On the contary, I believe that there are two parties
with different interests: one that prefers the distributed paradigm, and
one that prefers the centralized paradigm. I personally think that both
approaches make sense. But I know for sure that just as there are people
who feel severely hindered by a subversion-like approach, there are
others that would hate to work with the git "pile of crap". I estimate
that the git addicts are a minority -- but who knows?

"WARNING: This bug is visible to non-employees. Please be respectful!"

SUSE LINUX Products GmbH
Research & Development
< Previous Next >