On Thu, Sep 25, 2008 at 05:57:26PM +0200, Adrian Schröter wrote:
On Thursday 25 September 2008 17:49:49 wrote Peter Poeml:
On Thu, Sep 25, 2008 at 05:04:35PM +0200, Adrian Schröter wrote:
osc could for example checkout unexpanded, and check which changes have been merged. And keep conflicting changes like svn does with the conflicting changes in the files.
Well, link expansion happens on the server side... maybe it should be possible to expand the link based on *that* revision of the target package where the link still applied.
It would be possible, but what would be the benefit ?
osc would give you a working copy containing your changes. You could then properly (easily) diff against a checkout of the target directory, see what's going on and merge the changes.
That seems easier to me than juggling with reject files from failed merges.
well, that is way svn, cvs and so on is working. So I suppose they have some point ;)
Hm. Do we talk about something different maybe? osc does the same for resolving conflicts with diff3 as svn and svn. I don't see how this helps with the broken link. Or is your idea to apply the link patches as well as possible and then put the failed merge files in conflict state, have them resolved, and check back in? I don't know if this isn't more complicated than needed... All I want is that 1) the link doesn't break in the beginning ;) 2) I can at least see what's broken. A simple diff (or even working rdiff) would be fine for that. So I can fix the link. BTW, it could also help to store the link patches per file - in the last cleanup I did, the .changes file was mostly at fault. So it could be possible to get less rejects when only the merge attempt on the one problematic file fails.
It would mean that you revert the changes from others when you submit again.
I think such a checkout would result in a working copy that is not up to date - and thus can't be committed. So I don't see this danger.
What is needed is to fix your changes for the latest version what exists in the package where the link is pointing to.
Since this can conflict, it is not possible to do non-interactive. So I doubt it can be done on the server.
My idea is to just generate a directory of the last non-conflicting stage. So there wouldn't be a conflict. The assumption is that the link has applied at *some* point in the past.
okay, but how does it help you to adapt *your* changes instead of the other already accepted changes ?
Wel, I just need to see both versions of the package, and be able to compare them. I can easily see / checkout the target package, but not the link - this is the part that is difficult at this time.
What would also help is if the buildservice would give me *one* patch instead of 10, because a single patch would be much easier and more useful, than a (possibly long) series of stacked patches that (sometimes) revert each other and so on. (Been there...)
hm, could be done, I think, but esp. in case you submitted the first 3 already, they got just accepted later, you can not that easily merge patch 4 and 5 anymore for example.
Hm, I'm not sure what you mean with "first 3 submitted already". As far as I see, the stack of patches is applied serially and it would always be possible to make a single patch from it. Maybe an example helps: The package I had to sort out recently had several patches that incrementally changed something in one spot, reflecting my individual commits to get things right. Later, I had to merge the patches into the current source. It would have been much less work to merge a single patch, than first merging the first patch, resolving the rejects, then merging the second patch, resolving more rejects, and the next, and so on. The result was that I had to resolve three or four rejects for a single file. One patch would have made this much easier, especially since patch3 was partly reverting patch2.
bye adrian
--
Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de
Peter -- Contact: admin@opensuse.org (a.k.a. ftpadmin@suse.com) #opensuse-mirrors on freenode.net Info: http://en.opensuse.org/Mirror_Infrastructure SUSE LINUX Products GmbH Research & Development