On Friday 26 September 2008 12:15:36 wrote Peter Poeml:
On Thu, Sep 25, 2008 at 08:37:56 +0200, Adrian Schröter wrote:
On Thursday 25 September 2008 19:30:17 wrote Peter Poeml:
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...
Well, yes, my idea is that osc is apply the patches if the server fails to show the user the real problems (block X in file Y at line Z does conflict) instead of just showing a 404 api error.
How can osc apply the failing patches?
That would be fun - osc could (try to) apply the patches and fail with the first out of ten. Requiring manual cleanup. And then you'd try the next patch, failing and requiring cleanup again and so on and so on??? Uhm, that's not what I call helpful.
Again, it should of course do something similar like cvs/svn, where you have both changes in the same file. And the user need to go through his files to fix them
I have described this before, maybe another example helps:
The target package is openSUSE:Factory/subversion, the link is Subversion/subversion. The link is broken and I want to restore it to a working state. I get a checkout of the factory version and what I now need is a checkout of the link. Checking out the link (or updating my working copy) fails though, due to the link breakage, because the patches can't be applied anymore.
If it was _one_ patch, you could try to apply it, keep the rejects for the user to resolve manually, exactly like osc does now.
Well, that does not work for my 0.108 at least. I get only # osc up Link cannot be expanded: could not apply patch 'project.diff' independend if there is one patch or multiple. I guess there is no error handling at all yet in osc, when the source server can not handle the merge automatically, right ?
With a series of patches (as source links typically have), this is less practical.
So what I need to resolve the situation is a checkout of the link:
I fail to see how you can fix the link, when you check out in a way that everything applys. Do you want to show this by a later "osc up" ?
I want my sources, so that I can diff $factory_checkout $link_checkout. Once I'm able to see the modifications that the link has, I'm able to restore the link. (Manual process, but easy and straightforward.)
And I think people expect some help here from the tools, like they are used to from svn/cvs.
The changes file is a problem on its own, there are some ideas to handle changelog entries differently. Also to avoid patch breakages, but also for other reason (like classifing changes).
...
The changes file was something I had a suspicion for on its own, because source commits that don't happen via the buildservice but via the internal buildsystem modify the .changes file in transit, which would result in a 100% chance of breaking the link.
Somebody told me though that this isn't the case.
Kind of a user/tool error, it get only changed it was not correctly submitted.
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.
okay, it is true in the reverting case, otherwise I think it does not really matter. But I agree all changes (either by applying one big patch or running via all) need to get applied on disk when updating the sources. So the user has the chance to fix all conflicts at once.
I don't think there is a way (with patch(1)) to apply a further patch on a failed one (that left rejects), without cleaning up first. Maybe with diff3(1) this could be possible, but I think one would end up with lots of versions of each file, which could easily be too confusing.
okay, when it works much better with one file than we should consider to change this.
And unlike with "patch" command, matching chances can get ignored, instead of asking the user to use this patch "reverted", right ?
Possibly, yes, I'm not sure.
bye adrian -- Adrian Schroeter SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) email: adrian@suse.de -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org