Comment 1 Paul Webster 2011-12-05 07:56:53 EST

Part of the problem is that the SDK repo should have rebase=true set on its remote tracking branches.

For this, either the scripts need to be updated to set that on any branch checkout:

git config --add branch.R4_1_maintenance.rebase true

or the script runner has to set the global policy before branches are created (could also be done in the script, but could potentially change the user's settings):

git config --global --add branch.autosetuprebase always

Setting the global flag is a good policy in general for our usecases in the SDK.

PW

Comment 2 John Arthorne 2011-12-05 09:41:13 EST

In general there should never be non-trival merges or rebases here, but I suspect it happened this time because Kim manually fixed the team.map for a previous problem.

I like the local configuration option. Otherwise we are hammering the global config for some random user (kmoir, e4Build, or someone else who copied our scripts).

git config --add branch.R4_1_maintenance.rebase true

Comment 3 John Arthorne 2011-12-05 09:42:34 EST

Kim, I think the easiest way to recover here is to delete the releng.maps clone from the build machine entirely and let the build scripts clone a fresh copy.

Comment 4 Paul Webster 2011-12-05 09:49:57 EST

(In reply to comment #3)
> Kim, I think the easiest way to recover here is to delete the releng.maps clone
> from the build machine entirely and let the build scripts clone a fresh copy.

Once the team.map is fixed and pushed to the repo, it should be a moot point (it turns out those test runs Kim did without pushing caused the merge nodes in the first place).

But either the rebase property has to be added to all existing branches in that cache or the scripts updated and that repo deleted so that the branches are configured correctly in the future.

Also, we could put a status test before we add all the maps to see if there was a conflict on pull and abort the build.

PW

Comment 5 Kim Moir 2011-12-05 09:55:53 EST

I'll delete the repos on disk and fix the script.

Szymon, I think there is still a problem because I don't see the org.eclipse.ui.net bundle in the R3_7_maintenance branch under bundles/

plugin@org.eclipse.ui.net=GIT,tag=v20110525-1146,repo=git://git.eclipse.org/gitroot/platform/eclipse.platform.team.git,path=bundles/org.eclipse.ui.net

Comment 6 Tomasz Zarna 2011-12-06 04:11:40 EST

(In reply to comment #5)
> I don't see the org.eclipse.ui.net bundle in the R3_7_maintenance branch under bundles/

Isn't it the same issue as in bug 355509, comment 17?

Comment 7 Paul Webster 2011-12-06 06:01:04 EST

(In reply to comment #6)
> 
> Isn't it the same issue as in bug 355509, comment 17?

I think this one is because it was never branched in R3_7_maintenance (it exists in the R3_7 tag)

PW

Comment 8 Paul Webster 2011-12-06 06:03:36 EST

One way to fix it is:

git checkout R3_7_maintenance
git checkout R3_7 bundles/org.eclipse.ui.net
git add bundles/org.eclipse.ui.net
git commit -m "adding back org.eclipse.ui.net"

Or you can re-write R3_7_maintenance and remove the delete commit (but of course, all of your commits will have different hashes).

PW

Comment 9 Szymon Brandys 2011-12-08 07:10:04 EST

org.eclipse.ui.net is added to the R3_7_maintenance branch.

Comment 10 Szymon Brandys 2011-12-08 07:13:45 EST

I marked it fixed by accident. I think there is still work to do with scripts, see comment 5.

Comment 11 Kim Moir 2011-12-13 16:54:14 EST

Closing.

Fixing the scripts is covered in bug 366285.