Mailinglist Archive: opensuse-buildservice (253 mails)

< Previous Next >
Re: [opensuse-buildservice] Build synchronization bug?
  • From: "Dr. Peter Poeml" <poeml@xxxxxxx>
  • Date: Tue, 7 Nov 2006 22:55:32 +0100
  • Message-id: <20061107215531.GR4353@xxxxxxx>
On Tue, Nov 07, 2006 at 06:53:46PM +0100, Marcus Rueckert wrote:
> On 2006-11-07 09:44:58 -0800, Steve Beattie wrote:
> > On Tue, Nov 07, 2006 at 06:37:24PM +0100, Marcus Rueckert wrote:
> > > > While I can understand the above behavior occurring, this is *not* the
> > > > situation I'm talking about. I make all my change to my checked out
> > > > repo and do *one commit* (one invocation of 'osc ci') and then see *two*
> > > > builds; one of the precommit version of the package, and then a followup
> > > > build of the newly committed version.
> > >
> > > anyway. if you changed multiple files and run "osc ci" it will be
> > > uploaded as multiple requests atm. so this might be the explaination for
> > > the unneeded rebuilds.
> >
> > Ah really? Yes, indeed, one file gets deleted, one file gets added,
> > and the specfile gets modified. I would have thought a commit operation
> > would have been atomic. If true, that explains it.
>
> to be done. at the moment i wish we had svn as transport and could just
> use all the transaction magic from it. :) a simple post-commit for the
> "trigger-rebuild" hah... but that sounds to easy and i am sure mls will
> kill me for that idea. :)

explicit rebuilding? Yes, people have been arguing for it since day one ;)

_I_ would love if we had a WebDAV capable server (with delta extensions,
like subversion uses), so I (we) wouldn't need to invent anything anew,
in some (then) limited form. Or mayby Amazon's S3 API. (Or Google FS?
But I have only a vague idea about the latter.)

It would instantaneously allow to use a number of clients to mount the
filesystem, edit files, etc. (konqueror, davfs, libraries, ...)

On the other hand, if we actually used an svn client on the client side,
I think we would have a hard time to extend it with the features we
need. Not only commands like rebuild triggering and such. The entire
protocol that we use to access the API would need to be implemented. And
what osc does to supply the functionality of the svn client which we
need, is much more simple than it might look, it is done in like 1000
or 2000 lines of code. (Admittedly, osc is still very basic. I'm looking
forward to have time to work on it soon.)

Another reason against subversion which I have in mind is that I see a
long-term advantage in a slender and lightweight and specific
implementation -- which just suits our needs. In the spirit of Amazon S3
web services, or Google's stuff. Using a full-blown solution as starting
base will likely scale worse. Provided that we get the design right, we
are on the right way I hope...

And while I'm putting together my list of Christmas wishes: I _wish_ we
would use Digest Authentication instead of SSL+Basic, which sucks for
development because it makes debugging harder, and otherwise slows
things unnecessarily down. Digest auth is secure without SSL.

Peter
--
SUSE LINUX Products GmbH Bug, bogey, bugbear, bugaboo:
Research & Development A malevolent monster (not true?);
Some mischief microbic;
What makes someone phobic;
The work one does not want to do.
From: Chris Young (The Omnificent English Dictionary In Limerick Form)
< Previous Next >
Follow Ups