Hello, On Aug 11 10:50 Adrian Schröter wrote (shortened):
Am Dienstag, 11. August 2009 10:34:58 schrieb Johannes Meixner:
One needs transaction semantics when working on packages: 1. Begin of transaction 2. Change it 3. End of transaction
This isn't there by intention. Basically no scm implements it because it blocks other people and slow downs development. Usually first submitter wins and followers need to adapt.
I can not imagine any system right now, which solves social problems, in the end people need always to talk to each other if they work on same code.
A weak synchronization point preferably with a kind of weak locking before someone starts to change it (so that all others who also work on it are at least informed) and a strong synchronization point preferably with a kind of three way merge when changes are committed.
I do not understand how a weak synchronization point before blocks other people and slow downs development. The problem with the current build service is not the optimistic concurrency control policy at commit time, the problem is that nobody knows about others who may also work on a package until it is too late to start collaborating. Remember Coolo's mass-changes of packages. All others notice what Coolo did only when it was already done. If there was a "begin of transaction" the others could get at least informed before. But as you wrote - and as other threads here show - mutual information is not really within the scope of the build service but is left to the users of the build service to do it somehow on their own beside the build service via manual mails. In short: The build service is just what it is called, a plain build service but nothing more. This is o.k. for me - I did just misinterpret what it actually is.
As far as I know the current build service does even not implement real revision control (like e.g. SVN).
it does, check "osc log".
This is mostly useless for me: jsmeix@nelson:/obs $ osc log openSUSE:Factory cups shows all entries with "unknown" and "<no message>" but I know that I explicitely provided messages while I did "osc commit". In contrast in my own working copy directory jsmeix@nelson:/obs/Printing/cups $ osc log shows more info but still not my "osc commit" messages. In my own working copy directory I do not need such information very much because in my own working copy directory I know well what I did there. In contrast it is crucial to have meningful "osc log" messages when I query whatever package on the server to find out which revisions are of particular interest regarding a particular issue. Kind Regards Johannes Meixner -- SUSE LINUX Products GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany AG Nuernberg, HRB 16746, GF: Markus Rex