So now, hopefully armed with a deeper understanding of what the build service is trying to do and what it actually does, let me reply to the other things you said: On Friday, 17 April 2009 13:12:56 Adrian Schröter wrote:
I do not think it is a good idea to checkout out something different than to build against on the server.
Let me ask you a few questions: * Do you think it is a good idea that a checkout gives a result different from what you have checked in, with no easy or obvious way for you to see what has actually happened behind you back? * How sure can you be that what a checkout gives you matches what was built? (How about changes in the target project that happened after the build?) * Can you easily reproduce what was built when necessary? * How reasonable can a system be that can end up in a state where you cannot even check out what you have checked in anymore?
And your "really, really" indicates that you still not accept that our main goal is to show up changes and conflicts as soon as possible. But this is the approach of the OBS. We trigger builds automatically when something below changes, so we need also show conflicting source changes immediatly to all parties.
I don't know what you think it is that I'm proposing, but certainly not that. I'm not trying to take away source links from you. I'm not trying to stop the propagation of changes at build time. Source links as implemented today are broken. It is also clear to me by now that what there is a lack of understanding of what source links are acually supposed to do. Please let's think this all through together and fix it. It's not far from where we are today to something that actually works reliably, and makes sense too.
[...] we desperately need the server side merge for automatic package building from my point of view. And no, I am not aware how to do this with some other SVC systems (except you build code which is doing this on top).
All version control systems support branching and merging, albeit under different names. Version control in the build service is based on the very same operations. Even source links, except that they are not implemented right. Fixing the implementation is not rocket science either, we only need to get the concepts right first. Here is what I would like the build service client and server to do: * Checking out the current revision of a package, or any previous revision, should produce exactly that revision as it was checked in. If the package links to another package, the client should check if the current revision of the package checked out is based on the most recent version of the target package. If not, an obvious enough message should be printed to tell the user to perform a merge. * When the user decides to do a merge, a proper three-way merge should be done. The result is committed to the build service, resulting in a new revision of the link package. * When the build service builds a link package, it *also* does a proper three-way merge. (If there are merge conflicts, it gives up, of course.) This merge result is only used for that specific build, and thrown away at the end. (I trust that the build log contains the revisions of all packages involved.) This is almost the same as expanding a source link as done now, except that a three-way merge is more robust against mis- merges. Using the identical operation on the server as on the client ensures that users can easily reproduce the exact state of the sources of a package. Until we get there, we can keep expanding source links as we do now. The difference will be that it will be more difficult to reproduce the exact sources that a build was using. This is no different from the current state, though. * There will be cases when a user wants to merge with a more recent version of the target package, but not with the most recent version. Users will need that when trying to reproduce the sources that a package was built with, for example. This is not difficult to implement, but it needs to be supported. All of this requires to store which revision of the target package a link was generated against, and then a little bit of coding. (Not much actually, this looks more complex than it actually is.)
Otherwise we will not scale for getting stuff merged into Factory from multiple sides (so far the small autobuild group had to fix other peoples way too often. This will not work with even larger world wide groups. So we need to report this back automatically to let the submitter fix their stuff first).
What kind of reporting do you have in mind? When a change in a target package causes a merge conflict in a link package, this will result in a build failure, and hopefully the user will notice quickly enough. When the user checks out a package or updates his working copy, the client will warn if the target package has changed and ask the user to perform a merge. Nothing can be done about package maintainers who ignores build failures, and do not sync with the build service either. Thanks, Andreas -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-packaging+help@opensuse.org