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: Thu, 25 Sep 2008 20:37:56 +0200
  • Message-id: <200809252037.57336.adrian@xxxxxxx>
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.

I am unsure if we need a "resolved" handling like svn does, but allowing a
source checkout in any case is important IMHO. It is obvious that the user
has to fix stuff manually when there are conflicting changes.


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.

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" ?

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.

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

...

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.

I just guess the chance that we can improve the cleanup on the server is
higher with multiple patches. In case we know that the submission request
applied only the first 3, so we could remove only them in the source link and
keep the others.

Nothing what we have, but might be possible in future.

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.

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.

And unlike with "patch" command, matching chances can get ignored, instead of
asking the user to use this patch "reverted", right ?

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 >
Follow Ups