Community
Participate
Working Groups
+++ This bug was initially created as a clone of Bug #374974 +++ Now that we have eclipsebuilder in git, and using it for all "forward" work, it really should be "master. So, this bug is just to track that specific action. Before doing anything, will tag the current eclipsebuilder master as "finalVersionUsedBeforeMigrationTo_build.eclipse.org" or similar since it was the branch being used for building on the previous IBM machines ... in case we need to go back :) Then, if I'm beginning to understand git, I'd starting having everything fetched and current, then, In the Git Repositories view, expand Branches > Local, and select *master* and checkout. Select (local) branch *R4_2_primary* and select merge. [Not sure, but might have to then select "merge tool" to get an initial version worked into my local copy of master?] Under the circumstances, any conflicts at all I would simply select and say "add", signifying to take the R4_2_primary version as complete and correct one? Then commit/push Advice/eduction welcome. Naturally, of course, then I'd have to change build scripts to refer to "master" where they now refer to "R4_2_primary".
Because we're just "swapping" branches, we probably wouldn't want to do a merge (unless that was appropriate for the history). From the original bug, what we care about: R4_2_primary -> 4.2 build on eclipse.org R3_8_eclipse -> 3.8 build on eclipse.org master -> Obsolete 3.8 build on IBM build machine After we've tagged everything we care about :-) then we would reset the branches or create new ones to what we want, disable receive.denynonfastforwards temporarily, and then push up the new branches: R4_2_primary -> master R3_8_eclipse -> R3_development master -> R3_original or R3_IBM Eventually we'll probably start merging changes from master to R3_development to help build 3.8 on eclipse.org. PW
(In reply to comment #1) > Because we're just "swapping" branches, we probably wouldn't want to do a merge > (unless that was appropriate for the history). > Darn, failed my git test already. :) Your approach sounds fine by me, but I wouldn't know how to do that. > Eventually we'll probably start merging changes from master to R3_development > to help build 3.8 on eclipse.org. Maybe. I've opened bug 376217 specifically to getting 3.8 I builds working on build.eclipse.org. I mentioned in bug 374974 comment 33 that it MIGHT be easier to use the same "eclipsebuilder" since so similar, and handle differences with properties or things in "maps" directories. And, that is not to be fancy, but in my experience, the overall effort is less for little investment up front. But, have not investigated closely yet. (But have already encountered some problems where a fix was put in R3_primary eclipsebuilder, but not R4_primary eclispebuilder ... so having two branches that do almost exactly the same thing gets quickly harder to maintain. But, we'll see. So, Paul, do you want to do this "stream swap" or educate me how to do it? Are you off Friday? Monday? (I guess its not urgent, but I plan to work over weekend, so just wanted to coordinate this, since I'll have to change build scripts at same time ... and thought it would be best to do before going into "production mode" early next week.
I'll probably be off Friday and Monday, but for the stream swap here's what I'd do to eclipsebuilder: git checkout master git pull git branch R3_IBM_hardware git push origin R3_IBM_hardware:R3_IBM_hardware # this is necessary 'cause it's not a tracked branch git branch -D R3_IBM_hardware git reset --hard origin/R4_2_primary # if this following fails, then you have to set receive.denynonfastforwards # to false on /gitroot/platform/eclipse.platform.releng.eclipsebuilder.git # before you try again git push origin +refs/head/master:refs/head/master # put back receive.denynonfastforwards git checkout R3_8_eclipse git pull git branch R3_development git push origin R3_development:R3_development git branch -D R3_development PW
(In reply to comment #3) > I'll probably be off Friday and Monday, but for the stream swap here's what I'd > do to eclipsebuilder: > Perfect ... if I'm feeling brave, I'll get out my git books and give it a whirl.
Yes you don't want to do a merge here. A merge will "combine" the two branches and you could end up with changes from both branches. What you really want to do is make master exactly the same as R4_2_primary. To sanity check that you succeeded at the end, you can do: git diff master..R4_2_primary This should turn up no differences if everything went well.
how about if I try today ... around 3:30?
Ooops, should have been: git push origin +refs/heads/master:refs/heads/master I was missing the 's'
All done. I did have to (temporarily) set denynonfastforwards to false (and, funny file systems, had to do that as e4Build user, since even though had "group" permissions, the GUID bit is set and Dani owned the files, etc. ... but, done (and reset back to true). Doing the diff John suggested, git diff master..R4_2_primary actually does show some differences but think that's just because I ?foolishly? followed git's advice to "add some untracked files" I had so I couldn't lose them ... should have put them into R4_2_primary first, I guess. Now, I'll got though build scripts and change R4_2_primary to master ... and see how much trouble I've caused us :)
And, as a reminder (since I at first forgot), we continue to use the basebuilder from cvs from the R4_2_primary branch and not known plans to change that ... since hope to get rid of it soon enough :)
