How do I get past this OSC CI issue?
The version on the server is now newer than the version you checked out before your local change. I always solve this as follows, because anything else is a hassle: Copy your own changes or your local files. Delete the package locally. Check out the package again. Delete all files. Copy your files back in. Osc commit. Surely someone will now tell us that there is another way. That may be true. But this is the easiest and quickest way. Regards Eric Am 16. Juli 2024 19:34:24 MESZ schrieb Larry Len Rainey <llrainey15@gmail.com>:
Hello, Am Dienstag, 16. Juli 2024, 19:34:24 MESZ schrieb Larry Len Rainey:
It might sound too easy, but usually osc up fixes this and allows you to run osc ci afterwards. Since you modified quite some files, osc up might cause some merge conflicts. You'll need to edit these files and fix the conflicts, then use osc resolved $file to mark that file as resolved. Regards, Christian Boltz -- Gegen DOS-Attacken kann man sich wehren - meistens hilft es, Windows drüberzuspielen. [Martin Leyrer bei den Grazer Linuxtagen]
Hi Larry, Am 16.07.24 um 19:34 schrieb Larry Len Rainey:
First thing to try is "osc up", see if something gets a conflict during that update and if it does, fix the conflict and resolve it, then try again to commit. Conflicts will be indicated during osc up with C virtualbox.changes C virtualbox.spec You need to then edit the files, check for <<<<<< your changes ====== their changes >>>>>> resolve them and then mark the file as resolved with "osc resolved virtualbox.changes" This happens if someone changed the package after you last updated it. In this case of a branch in your home, probably the branched package has been updated, maybe just by an accepted submitrequest from Virtualization to Factory or such, which usually does just increase the checkin counter but not create any real conflicts. Real conflicts only occur if multiple people are doing changes to the package at the same time. Hope this helps a bit :-) You can also use the "smash everything with a big hammer" method that someone else suggested with deleting everything and trampling over the changes of others. But that should be the last resort IMVHO. Best regards and good luck, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
The version on the server is now newer than the version you checked out before your local change. I always solve this as follows, because anything else is a hassle: Copy your own changes or your local files. Delete the package locally. Check out the package again. Delete all files. Copy your files back in. Osc commit. Surely someone will now tell us that there is another way. That may be true. But this is the easiest and quickest way. Regards Eric Am 16. Juli 2024 19:34:24 MESZ schrieb Larry Len Rainey <llrainey15@gmail.com>:
Hello, Am Dienstag, 16. Juli 2024, 19:34:24 MESZ schrieb Larry Len Rainey:
It might sound too easy, but usually osc up fixes this and allows you to run osc ci afterwards. Since you modified quite some files, osc up might cause some merge conflicts. You'll need to edit these files and fix the conflicts, then use osc resolved $file to mark that file as resolved. Regards, Christian Boltz -- Gegen DOS-Attacken kann man sich wehren - meistens hilft es, Windows drüberzuspielen. [Martin Leyrer bei den Grazer Linuxtagen]
Hi Larry, Am 16.07.24 um 19:34 schrieb Larry Len Rainey:
First thing to try is "osc up", see if something gets a conflict during that update and if it does, fix the conflict and resolve it, then try again to commit. Conflicts will be indicated during osc up with C virtualbox.changes C virtualbox.spec You need to then edit the files, check for <<<<<< your changes ====== their changes >>>>>> resolve them and then mark the file as resolved with "osc resolved virtualbox.changes" This happens if someone changed the package after you last updated it. In this case of a branch in your home, probably the branched package has been updated, maybe just by an accepted submitrequest from Virtualization to Factory or such, which usually does just increase the checkin counter but not create any real conflicts. Real conflicts only occur if multiple people are doing changes to the package at the same time. Hope this helps a bit :-) You can also use the "smash everything with a big hammer" method that someone else suggested with deleting everything and trampling over the changes of others. But that should be the last resort IMVHO. Best regards and good luck, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
participants (5)
-
Axel Braun -
Christian Boltz -
Eric Schirra -
Larry Len Rainey -
Stefan Seyfried