Mailinglist Archive: opensuse-buildservice (269 mails)

< Previous Next >
Re: [opensuse-buildservice] how to verify and fix broken links?
  • From: Adrian Schröter <adrian@xxxxxxx>
  • Date: Fri, 26 Sep 2008 15:03:05 +0200
  • Message-id: <200809261503.05296.adrian@xxxxxxx>
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@xxxxxxx

--
To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-buildservice+help@xxxxxxxxxxxx

< Previous Next >