Adrian Schröter wrote:

On Thursday 25 September 2008 11:13:06 wrote Wolfgang Rosenauer:

...

Ludwig Nussel schrieb:

...

Suppose I have a package linked from another project with patches (project*.diff) on top of it. Now the other package is updated and the patches no longer apply. osc rdiff doesn't work because it can't apply the patches either. How do I verify how and which of my changes got applied to the linked package?

very valid question. I'm interested in the answer since that took quite some time out of me already :-( (Pretty annoying, even more if that happens in the development project when someone is changing the package on a lower level what happened in the past sometimes :-()

the best thing, what you can do currently is to checkout unexpanded (osc co -u) and verify the patches manualy.

In this case it would be nice if the build service could freeze the link at the last known to work version. One could run rdiff then. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) --------------------------------------------------------------------- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org

On Thu, Sep 25, 2008 at 04:52:45PM +0200, Adrian Schröter wrote:

On Thursday 25 September 2008 16:47:38 wrote Peter Poeml:

...

On Thu, Sep 25, 2008 at 10:59:23AM +0200, Ludwig Nussel wrote:

...

Hi,

Suppose I have a package linked from another project with patches (project*.diff) on top of it. Now the other package is updated and the patches no longer apply. osc rdiff doesn't work because it can't apply the patches either. How do I verify how and which of my changes got applied to the linked package?

I had the same at least two times, and it was a bug mess and manual work to sort it out.

Especially, it seems it can happen with applying submit requests - which is the following bug, I assume? https://bugzilla.novell.com/show_bug.cgi?id=426236

sure, if an intermediate state gets submitted, this can happen. We can improve this maybe in the server side clean up, but we need in any case a better handling of not matching patches in our frontends.

I don't understand the circumstances when it happens very well. An observation was that it might have to do with another submission (of conflicting changes) to the target project.

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.

I dunno if there are standard tools around which can get utelized for this.

bye adrian

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

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.

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. 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...) 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

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

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. 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. 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.)

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.

...

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.

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. Peter -- "WARNING: This bug is visible to non-employees. Please be respectful!" SUSE LINUX Products GmbH Research & Development

On Friday 26 September 2008 12:51:15 wrote Martin Mohring:

I have a question on all this: Would it be possible to implement more smart links, e.g. links that can reference to a specific version of software it is linking to?

That is already possible. But this is in most cases not the want way to go. Since you need to see if other people changes still work with yours. At least when you plan your changes to the other project.

Then a user could decide if he want to come into the treatmill of automatically changing his own source whenever the source makes a breaking change or to be in the situation of beeing forced something in the own code?

Currently, linking can break the revisioning in the sense that you cannot reproduce results when linking to a moving target.

At least, the user of links should be able to decide if he wants the "free running" mode or the versioned one. Would it be complicated to implement versioned links?

it already exists ;) Just add a rev= attribute to the link. 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

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

On Thu, Sep 25, 2008 at 05:07:52PM +0200, Michael Schroeder wrote:

On Thu, Sep 25, 2008 at 04:58:55PM +0200, Peter Poeml wrote:

...

I don't understand the circumstances when it happens very well. An observation was that it might have to do with another submission (of conflicting changes) to the target project.

There are two possibilities how broken links can happen:

1) the link target was modified because of another submission and your patch set no longer applies.

I'm not sure if I have had this case. In fact, I thought that some of the changes that were to be submitted (via submit request) were already applied "upstream". But then it wouldn't be possible anymore that the submit request gets applied. I'm not exactly sure if it was in my last case - I thought so at least.

2) you continue changing your packet after you created a submit request. osc creates the request with a revision, i.e. exactly this revision is checked in.

If you continued to change your package, your new patch set can no longer apply. The backend could also not replace the link with an empty link (as you added new stuff, which would get lost otherwise).

This is basically 1) with just the difference that it's not a submission from another person, but your own submission that kills the link.

It wouldn't happen if the submit revision contained no revision, but maybe this is also not the right solution.

I see. I haven't thought this far before.

Cheers, Michael.

-- Michael Schroeder mls@suse.de SUSE LINUX Products GmbH, GF Markus Rex, HRB 16746 AG Nuernberg main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}

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