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)