Community
Participate
Working Groups
org.eclipse.ui.internal.views.markers.ConfigureColumnsHandler has 3 compile errors (the JFace class has been moved, I believe) Description Resource Path Location Type The import org.eclipse.jface.internal.ConfigureColumnsDialog cannot be resolved ConfigureColumnsHandler.java org.eclipse.ui.ide/src/org/eclipse/ui/internal/views/markers line 15 Java Problem This will break the build. PW
Paul: Is there any coordinated effort to rebase e4 on the 3.5m6 baseline? James: Could you help out with such rebasing resources, using your git repo?
There is no coordinated re-basing effort. Paul raised this in e4-dev but didn't get much response.
I checked in a temporary fix for the errors. (In reply to comment #1) > Paul: Is there any coordinated effort to rebase e4 on the 3.5m6 baseline? > James: Could you help out with such rebasing resources, using your git repo? AFAIK we will be building e4 M2 on eclipse M6 (and as much of Galileo M6 as I can get my hands on). I'll move up to the I build this week to prepare. I haven't heard back from the list (http://dev.eclipse.org/mhonarc/lists/e4-dev/msg00720.html) about someone changing the current fork of org.eclipse.ui.ide to the proposed way (or volunteering to keep it up to date), right now that just defaults to the "general resources team". And of course most of the resources work itself is based on forked resources projects. It was originally discussed here, http://dev.eclipse.org/mhonarc/lists/e4-dev/msg00026.html PW
But if we rebase resources only without UI, we risk yet other breakage, no? Given that M6 should be API freeze there are good chances that this would be the one and only rebasing (at least until the 3.5 release). I'd vote for going for it.
(In reply to comment #1) > James: Could you help out with such rebasing resources, using your git repo? When you say rebase do you mean: recreate the e4 repo from current HEAD, and reapply the patchsets that were previously applied to e4; or do you mean merge the changes made since the branch point, into current e4 HEAD? Obviously rebasing would break everyone's existing checkout (but history would be neater, and the process potentially simpler), merge might incur more headache. As it happens in ui.ide the number of patchsets applied to HEAD dwarf those applied to e4, so a traditional rebase would probably be relatively straightforward: See the black and blue line on: http://github.com/jamesblackburn/eclipse-ui-ide/network (note the graph scrolls...) AFAIK there have only been bugfixes, with no API breakage in core.resources: http://github.com/jamesblackburn/eclipse-core-resources/network Though the patches here should be brought over into e4... What mechanism were you proposing to actually perform the merge / rebase? If I were doing this, I'd be tempted to start from CVS HEAD. And reapply the e4 patchsets one at a time, though perhaps there's a better way? I'm happy to help out if I can.
Hi James, By rebasing I basically meant synchronizing the 3.5 and e4 streams, without changing the branching point. Sorry for not being precise. I don't think that a "traditional rebase" that makes people's existing workspaces invalid is the right thing. Too disruptive to all the committers, contributors and occasional followers. So, apparently there's two possible approaches: (a) apply diffs between 3.5m4(original branchpoint) and 3.5m6 (current 3.5 Stream) into the e4 repo, or (b) Get an e4 head checkout, override all with a fresh 3.5m6, apply the diffs between branchpoint and e4-head, then commit everything into the e4 repo (overriding any merge conflicts). If you say that on ui.ide the set of changes in 3.5 land is much larger, it looks like option (b) is what we want. The simplest solution may differ from bundle to bundle. I only think it's important to do it for ALL bundles or we'll be stuck with such incompatibilities as the one in this bug forever. We can't do much about the history anyways, I guess in e4 land we'll have to live with history entries like "update to 3.5m6" instead of the individual commit comments for each change in the 3.5stream.
(In reply to comment #6) > I don't think that a "traditional rebase" that makes people's existing > workspaces invalid is the right thing. Too disruptive to all the committers, > contributors and occasional followers. That makes sense. > If you say that on ui.ide the set of changes in 3.5 land is much larger, it > looks like option (b) is what we want. The simplest solution may differ from > bundle to bundle. I only think it's important to do it for ALL bundles or we'll > be stuck with such incompatibilities as the one in this bug forever. Well you shouldn't have to manually generate such a patch. For one thing it'd never apply (and pity the person that has to resolve the conflicts... ;)). Given that I've got both repos in one git repo (for this bundle), I'll have a go and see how git-merge fairs. It should handle cases like patches applied to both branches which a simple patch application wouldn't. If all goes well I'll attach a patch for e4 head which brings it into line with 3.5. BTW I'm currently only tracking core.resources, core.tests.resources and ui.ide in this way. Is there a list of bundles which need merging?
(In reply to comment #7) > If all goes well I'll attach a patch for e4 head which brings it into line with > 3.5. I'll make some time this evening (UK) to look at this, if someone else wants to address this before then, then that's fine too.
(In reply to comment #7) > BTW I'm currently only tracking core.resources, core.tests.resources and ui.ide > in this way. Is there a list of bundles which need merging? Well as I've said before, I think we're at risk unless we move everything up to 3.5m6 that we have in e4. Remember that when installing e4, we're patching an existing runtime (3.5m6 typically). If anything in that existing runtime calls into stuff that we patch but haven't upgraded, it's bound to fail. The only exception that I am aware of is the SWT stuff (dojo and flex ports), since AFAIK these are developed in the main eclipse repository in HEAD anyways (adding steve to verify).
(In reply to comment #9) > Well as I've said before, I think we're at risk unless we move everything up to > 3.5m6 that we have in e4. Remember that when installing e4, we're patching an > existing runtime (3.5m6 typically). If anything in that existing runtime calls > into stuff that we patch but haven't upgraded, it's bound to fail. Sure. As I haven't used anything else from e4, I need to go through the repo and work out what else needs merging. Martin: I don't think the bug should be assigned to me as I'm not an e4 committer. I'm happy to attach some patches but I won't be able to apply them. Reassigning to inbox for now.
Hi James, thanks so much for helping out. I had assigned this to you because of your comment #8: > I'll make some time this evening (UK) to look at this, if someone else wants to > address this before then, then that's fine too. You essentially said that you'd take this, I.e. you claimed ownership -- which is sufficient in my opinion to make you an assignee, in order to clarify to the rest of the community that there is already someone who cares. I'd reassign to a committer once your patch is there and it gets handed over. In general, I think it's a bad thing having bugs pile up in the inbox since we quickly lose track of what's been triaged (i.e. at least looked at once). Moving off the inbox can be done by assigning a person, setting some target milestone, or other fancy tricks like component tags in the subject line. The Platform UI team recently invented a new strategy involving a second kind of inbox (platform-ui-triaged) which I also found cool: http://wiki.eclipse.org/Platform_UI/Bug_Triage In my project (TM) I assign to a person (committer or not) as soon as it's clear who cares and thus "owns" the bug. That's just a matter of process and not all that relevant, and since I'm not sure how we want to do this in e4 land I'm going to leave the inbox for now.
Created attachment 128476 [details] org.eclipse.ui.ide patch1 So git made it very easy indeed. I wrote a bit of wiki on what I did to generate this patch: http://wiki.eclipse.org/Git_for_Committers#Merging_HEAD_changes_to_e4 Git auto-merged nearly everything. Some stats (and explanation on what I did in both cases): 85 files merged 5 requiring manual merge: src/org/eclipse/ui/internal/ide/dialogs/PathVariableDialog.java Serge's work Conflict with bug204879 path variable button possitioning is confusing (I plumped for serge's changes as this dialog has changed lots for e4) src/org/eclipse/ui/internal/ide/dialogs/ResourceInfoPage.java Serge's work + font fix bug175069 Trivial-merges: plugin.xml plugin.properties src/org/eclipse/ui/views/tasklist/FiltersDialog.java The command: git log --merge -p src/org/eclipse/ui/internal/ide/dialogs/ResourceInfoPage.java is magic. For the given file in conflict, it shows you the commits' log messages & short-diff on both (/all) the branches you're merging if the commits don't exist on the other branch. This makes it really easy to see who changed what when, and quickly work out why they changed what they did. It would obviously be a good idea for people (Serge et. al.) to review this patchset, and the conflicts highlighted in particular.
Created attachment 128477 [details] org.eclipse.core.resources.patch org.eclipse.core.resources 3 manual merge: src/org/eclipse/core/internal/resources/Project.java Trivial: META-INF/MANIFEST.MF src/org/eclipse/core/resources/IWorkspace.java The conflict in Project.java was for the unnecessary deltas issue in bug265810. I've brought over this 'trivial' change to the groups / linked resources world. Serge, please review.
Created attachment 128478 [details] org.eclipse.core.tests.resources org.eclipse.core.tests.resources 1 manual merge Trivial: META-INF/MANIFEST.MF
I've pushed my merge branch up, so you can see how the merge looks graphically: The branches are at: http://github.com/jamesblackburn/eclipse-core-resources/tree/e4_3.5m6_merge http://github.com/jamesblackburn/eclipse-ui-ide/tree/e4_3.5m6_merge http://github.com/jamesblackburn/eclipse-core-resources-tests/tree/e4_3.5m6_merge Click on 'network' at the top to see the branch graphs. Needless to say all three plugins build, though I haven't run any tests.
(In reply to comment #11) > You essentially said that you'd take this, I.e. you claimed ownership -- which > is sufficient in my opinion to make you an assignee, in order to clarify to the > rest of the community that there is already someone who cares. I'd reassign to > a committer once your patch is there and it gets handed over. Ah, ok. I've just never seen a bug assigned to a non-committer before. As stated in the previous comment, I haven't yet imported any other plugins as I haven't had the need. If there's an order of priority / if people want me to continue merging like this, I can do? Given how 'easy' this was (i.e. git did nearly all the work). I was thinking about how neat it would be to tweak (rewrite) the commit which corresponds to the merge once it's cvsimport'd. Doing this I would mark the commit as a merge of the two branches rather than a plain commit along the e4 branch. The merge point would then persist forever more making future merges that much easier (the tool knows the new branch point) and allowing tracing the lineage of lines of code! One of the things which bothers me about cvs is that, whoever applies the giant patch now has ownership of the code touched (in the e4 repo). There is no concept of where the changes originated. In the git world 'git blame' still does what cvs annotate does - except better - as the merge commit knows both ancestor branches are parents, so all the previous commits on both branches persist!
(In reply to comment #16) Hey James, you're awsome :-) > I haven't had the need. If there's an order of priority / if people want me to > continue merging like this, I can do? I'm actually wondering if you see any potential for automating some of the work you have done? E.g. if we end up doing daily automated merges, the risk of conflict may be much smaller since the chunk of changes is smaller... > Given how 'easy' this was (i.e. git did nearly all the work). I was thinking > about how neat it would be to tweak (rewrite) the commit which corresponds to > the merge once it's cvsimport'd. Hm, I'm not sure I understand. Are you in favor of doing "cvs import" for any merges and then "cvs update -j" to merge over the merge branch? How else would you mark up the branch point, or trace lineage of code? > One of the things which bothers me about cvs is that, whoever applies the > giant patch now has ownership of the code touched (in the e4 repo). > There is no concept of where the changes originated. Yes, that's a very valid concern... personally, it bothers me less in terms of IP (since the EPL allows us to copy stuff around), but it does bother me that I cannot find out easily from CVS who's done any particular change. On the other hand, just assuming that we might have a synthetic committer like "Eclipse genie" for committing merges only, we'd be aware that a change comes from 3.5 and can be looked up there. > In the git world 'git blame' still does what cvs annotate does - except > better - as the merge commit knows both ancestor branches are parents, > so all the previous commits on both branches persist! So, as long as your repo's around anybody can leverage it with "git clone", right? Thanks again!
(In reply to comment #17) > I'm actually wondering if you see any potential for automating some of the work > you have done? E.g. if we end up doing daily automated merges, the risk of > conflict may be much smaller since the chunk of changes is smaller... Yes, that would be good. Interestingly the conflicts I hit were due to the integration of Serge's features where the original file was tweaked subsequently in HEAD. Therefore this wouldn't have helped (i.e. merging frequently keeps the e4 guys in step with HEAD, but doesn't prevent the HEAD guys from creating conflicts). Currently my tracking of cvs/HEAD and e4 is entirely automated. If we wanted to merge once a day, say, it's a handful of commands to script the process including generating a mail detailing the conflict commits and appropriate diff. Apart from anything else, recent commits are fresh in people's mind, making it much simpler to resolve. I'm not sure of the processes at eclipse.org (my unix account is apparently now being provisioned for tools.cdt :) ), but at some level this would require committer interaction to resolve conflicts when they happen. It might involve the developer responsible driving some wrapper script over a git/cvs hybrid checkout on an eclipse.org box? Or there could be one designated person who resolves all such conflicts as best he can (making sure the product still builds) and notifying the list for further input? Developers can subsequently tweak the code if they disagree with the merge decision made? The result would be continuous integration between 3.x and e4 which must be a 'good thing'. > >I was thinking > > about how neat it would be to tweak (rewrite) the commit which corresponds to > > the merge once it's cvsimport'd. > > Hm, I'm not sure I understand. Are you in favor of doing "cvs import" for any > merges and then "cvs update -j" to merge over the merge branch? How else would > you mark up the branch point, or trace lineage of code? Whoops. I was a bit unclear. My comment had nothing to do with CVS, rather it would be a neat tweak to the git cvsimport process to internalise the merge. Currently if someone applies a patch representing the merge into cvs, to the git import it will look like just-another-commit. The merge metadata (which by convention might be some particular commit comment) isn't interalised into the repository. So while we can look at the commit logs and work out when the merge points were, git has no knowledge that the current tree state is derived from both branches - HEAD and e4 HEAD. If it did know about the merge point, then a bunch of things would work better: 1) Subsequent merges: knowing the last merge point is important so we don't have to resolve conflicts already resolved again and again (and we don't try to reapply already applied changesets). 2) Intact history: We can track the lineage of lines of codes from both branches (git blame) Effectively I would like git cvsimport to generate a tree state that looks like the e4_3.5m6 branch I linked to earlier. If we were to use a tool like git to do continuous integration merging internalizing this would probably be essential. Note cvs and svn pre 1.5 have the same problem as (1): you need to specify / know the previous merge point when performing the next merge. Internalising this metadata requires having both branches in the same repo, and using a VCS that understands branch and merge points. > Yes, that's a very valid concern... personally, it bothers me less in terms of > IP (since the EPL allows us to copy stuff around), but it does bother me that I > cannot find out easily from CVS who's done any particular change. On the other > hand, just assuming that we might have a synthetic committer like "Eclipse > genie" for committing merges only, we'd be aware that a change comes from 3.5 > and can be looked up there. And to add to this, if we keep the git clones of the Eclipse CVS repository in step, git users can just ignore this issue altogether as "It just works". > So, as long as your repo's around anybody can leverage it with "git clone", > right? Yes! And furthermore it really is worth trying this for yourself. Submitting large patches to bugzilla is pretty opaque. If someone doesn't trust me, they'd have to read the entire patch to check whether I'd messed up. (And if someone had created a merge-patch by hand, I wouldn't trust it. I would have no way of verifying that they had included everything other than by doing the merge myself and comparing.) Verifying these results couldn't be more straightforward. As outlined in the wiki: 1) Clone the github repo for the plugin you're interested in 2) Create a new branch tracking origin/cvs_e4/HEAD 3) Merge origin/cvs/HEAD 4) Resolve conflicts 5) Verify by diff'ing your branch to my 3.5m6 merge branch and see what differences you've got. As it happens I've detailed the conflicts and how I resolved them. But fundamentally it should be straightforward for anyone else to verify what I've done (in a matter of minutes, not hours)! I'm off tomorrow and at the weekend, so realistically I won't get a chance to look at any of the other plugins before next week :s... Is there any way I can help make the process easier / more transparent?
Assigning to Serge to review James' conflict resolutions (comment 12 and comment 13)
(In reply to comment #17) > I'm actually wondering if you see any potential for automating some of the work > you have done? E.g. if we end up doing daily automated merges, the risk of > conflict may be much smaller since the chunk of changes is smaller... Given this bug is for o.e.ui.ide, is it worth filing another bug for the job of automating the merge process?
IMO we have to apply the merge patches for m2, in order to remain current and clean for basing m2 on Eclipse 3.5m6. I've also brought this up on the e4 mailing list.
(In reply to comment #5) > As it happens in ui.ide the number of patchsets applied to HEAD dwarf those > applied to e4, so a traditional rebase would probably be relatively > straightforward: See the black and blue line on: > http://github.com/jamesblackburn/eclipse-ui-ide/network In CVS, a traditional rebase would mean: 1. Update to e4 HEAD, create a label "BEFORE_3.5m6_MERGE" 2. Create a patch of diffs compared to label "e4-root" (this was the label we created when bringing over e3.5 initially) 3. Verbatim copy of e3.5m6 version into e4 and commit (note: this interim commit will break things because of invalid bundle versions in MANIFEST.MF, but it's needed for a full traditional rebase) 4. Label as "e4-root-3.5m6" and probably also move label "e4-root" 5. Apply patch from (1), and/or compare against BEFORE_3.5m6_MERGE to resolve conflicts Applying the patch from (1) will lead to exactly the conflicts outlined in comment 12 and comment 13. Given that we know the list of conflicts already, resolving these should hopefully be straightforward. I'd hate going with such tedious and error-prone manual merging, given that other tools (git) can help us a lot more. We could also think about CVS style branch tracking with "cvs import" / "cvs update -j" commands, but that's not much better than the manual approach...
(In reply to comment #22) > In CVS, a traditional rebase would mean: > ... I think that's a rebase in any version control. i.e. re-create a branch from it's parent's current HEAD and reapplying the branches patches to the new 'base'. A 'merge' creates an equivalent tree state at the end of the operation (in terms of file content). Intermediate history is different. Whereas rebase loses the apparent history of the branch being 'rebased', merge preserves both histories, and in a decent VCS you can trivially trace the heritage of any line of code. A question for the e4 guys: what other bundles would need to be merged for M6? The only other common plugins I can see are under resources: _Resources_: Bundles: org.eclipse.core.contenttype org.eclipse.core.filesystem.* org.eclipse.core.resources.* org.eclipse.ui.ide Tests: org.eclipse.core.resources.* org.eclipse.core.tests.resources.* org.eclipse.core.tools.resources Looking at the e4 repo, org.eclipse.ui.tests isn't in e4. Am I missing anything else?
I did some further diligence on this. Ran all the core.tests.resources on MacOSX. They all pass apart from these in IContentTypeManagerTest: testAlias testDynamicChanges testInvalidMarkup testNoExtensionAssociation testOrphanContentTypes NB these same tests also fail on the base 3.5 platform (I20090310-0100), so as far as I can see the test results are identical. The other forked resources plugins don't look particularly interesting / like they change frequently. If I'm wrong, do say.
The bug summary is confusing. Shouldn't we change it to "Rebase e4 resources onto m7". James, could you prepare Eclipse patches using those attached already?
(In reply to comment #25) > James, could you prepare Eclipse patches using those attached already? Nevermind :-) I can apply them.
Szymon, the target milestone is 0.9m2. I think we need to rebase on m6. What are you missing in James' existing patches? They seem good enough to me. OK they are not "eclipse workspace patch" but you know that the patch root is the respective plugin (o.e.core.resources and o.e.c.t.resources respectively).
(In reply to comment #25) > The bug summary is confusing. Shouldn't we change it to "Rebase e4 resources > onto m7". And as a minor point, can we use the terminology 'merge' rather than 'rebase' as technically it's merging changes since the branch point instead of rebasing ;) I can generate patches as and when (as can anyone else). Let me know if you want me to do this. Grok'ing / reviewing the flat patches is not entirely straightforward. Using a gui on top of the git repo checkout (gitk --all) will show the actual changes made in the merge commit which aren't in either of the merged branches (i.e. the conflict resolution). Although the Eclipse compare viewer is also pretty good (if you're a committer and knows about all these changesets in the first place).
(In reply to comment #27) > Szymon, the target milestone is 0.9m2. I think we need to rebase on m6. Sorry, too much Ms. I'm on M7 right now and of course I meant M6. > What are you missing in James' existing patches? They seem good enough to me. > OK they are not "eclipse workspace patch" but you know that the patch root is > the respective plugin (o.e.core.resources and o.e.c.t.resources respectively). True. Se my comment 26.
(In reply to comment #14) I've just looked at the resources patches to be sure that all the necessary changes are picked up from M6. Both core.resources and core.resources.tests looks fine to me. I noticed some changes in core.contenttype that probably should be included while merging.
Created attachment 129307 [details] core.contenttype.patch (In reply to comment #30) > (In reply to comment #14) > I noticed some changes in core.contenttype that probably should be included > while merging. Ok. Patch attached. Same technique as before, only conflict was in MANIFEST.MF (plug-in version number). Repo: http://github.com/jamesblackburn/eclipse-core-contenttype/ Graph: http://github.com/jamesblackburn/eclipse-core-contenttype/network
Awsome. I assume that as we're moving forward, merges may even become easier since the initial conflict in MANIFEST.MF will be resolved already - provided that git keeps the information about the merge and conflict resolution that has already happened, which I'm sure it does. Moving forward, only the diffs against m6 need to be applied to e4, and infrastructure work such as MANIFEST bundle version won't change in e4 for sure. Thanks James for making this happen!
Martin, could you remind me what Eclipse version was used when resources plug-ins were initially moved to e4? I think it was somewhere in September or even earlier. If yes, I would ask James to prepare the patch for core.filesystem too.
(In reply to comment #33) > Martin, could you remind me what Eclipse version was used when resources > plug-ins were initially moved to e4? Hi Szymon, I have mentioned this in comment 22 but the answer was somewhat hidden: The CVS Repository files have been moved by John on and HEAD of those files was tagged with the label e4-root before any e4 development began. That is, you'll get the e4 specific diffs by simply comparing HEAD against e4-root. As I have also mentioned in comment 22, I'd strongly recommend applying some labels for the merge to m6: BEFORE_3.5m6_MERGE MERGED_3.5m6 (or: e4-root-3.5m6-merge) these labels may help to simplify other merges in the future, and are easy to apply now. In case we shouldn't need them, they can also be removed very easily again.
I don't know if you need the actual date when you have the label; but it looks like the move was done between 31-oct and 14-nov; more concrete, I believe it must have been after 10-nov-2008 since that's when Boris wrote on the mailing list that the project has been provisioned. http://wiki.eclipse.org/E4/Resources/Meeting/14-Nov-2008
(In reply to comment #35) > I don't know if you need the actual date when you have the label; but it looks > like the move was done between 31-oct and 14-nov; more concrete, I believe it > must have been after 10-nov-2008 since that's when Boris wrote on the mailing > list that the project has been provisioned. > > http://wiki.eclipse.org/E4/Resources/Meeting/14-Nov-2008 If you knew exact plug-in tags used to sync plug-ins between 3.5 and e4, we could use 3-way compare to merge changes. It's actually very handy. The only condition is to have plug-in in the state when it was synced previously. Steps (for core.filessytem): 1) Check out org.eclipse.core.filessytem from HEAD 2) Check out org.eclipse.core.filesystem from e4 and rename to org.eclipse.core.filesystem.e4 3) Checkout org.eclipse.core.filesystem using the version used during previous sync 4) Select all three, use "Compare with Each Other" and set (3) as ancestor 5) In the compare editor, you'll see all the changes incoming from 3.5 If we track versions used while syncing, we could make the process very easy and I could do the sync for instance at the end of each week.
(In reply to comment #36) > If we track versions used while syncing, we could make the process very easy > and I could do the sync for instance at the end of each week. That would be great! Feel free to use the tool that you feel you are most productive with. Nobody here is married with git :) and if we can stay close in sync with the 3.5 stream with very little effort that's awsome. Why don't you just track the time that you actually need for a weekly merge? As James is likely going to be committer, he can perhaps also do a merge with git, track his time, and then we compare.
Created attachment 129394 [details] core.filesystem.patch (In reply to comment #33) > I think it was somewhere in September or even earlier. If yes, I would ask > James to prepare the patch for core.filesystem too. Attached. No conflicts during the merge.
(In reply to comment #34) > (In reply to comment #33) > As I have also mentioned in comment 22, I'd strongly recommend applying some > labels for the merge to m6: > BEFORE_3.5m6_MERGE > MERGED_3.5m6 (or: e4-root-3.5m6-merge) > these labels may help to simplify other merges in the future, and are easy to > apply now. In case we shouldn't need them, they can also be removed very easily > again. Yes, that's a very good idea. This is probably obvious, but these tags should be in the 3.x repo as it's the reference point for the next 3-way merge. (In reply to comment #37) > (In reply to comment #36) > > If we track versions used while syncing, we could make the process very easy > > and I could do the sync for instance at the end of each week. > > That would be great! Feel free to use the tool that you feel you are most > productive with. Nobody here is married with git :) and if we can stay close in > sync with the 3.5 stream with very little effort that's awsome. > > Why don't you just track the time that you actually need for a weekly merge? As > James is likely going to be committer, he can perhaps also do a merge with git, > track his time, and then we compare. Szymon's approach is more thorough, and definitely the way to go if we can convince a committer to keep things in sync :). My way requires less manual intervention (those fated 3 commands) but the results haven't been human verified (apart from being built). Ideally the changes would be reviewed as Szymon is doing and it definitely makes sense that the committer who knows about these changes is the one doing that! Both involve a 3-way merge, so it's pretty essential that we recognise the most recent merge point by tagging the commit with either a special comment, a repository tag, or both. I'll aim to internalise this metadata into my git repo. so it can continue to do the automatic 3-way merges.
(In reply to comment #32) > Awsome. I assume that as we're moving forward, merges may even become easier > since the initial conflict in MANIFEST.MF will be resolved already - provided > that git keeps the information about the merge and conflict resolution that has > already happened, which I'm sure it does. > > Moving forward, only the diffs against m6 need to be applied to e4, and > infrastructure work such as MANIFEST bundle version won't change in e4 for > sure. Slightly off-topic... For your initial question, yes it does do the right thing. It performs a 3-way merge from the last merge point. Your comment about the version-number conflict I saw got me thinking, so I had a quick play. Yes the e4 version number doesn't change, but the 3.x version number does. Having merged once you wouldn't want a 3.x version number change to override the e4 version number... git does the right thing: Branch Content master: Version: 1.0.0 feature: change Version: 2.0.0 master: change Version: 1.1.0 *merge master->feature* => *conflict* *resolve* master: change Version: 1.2.0 *merge master->feature* => *conflict*
(In reply to comment #33) > I think it was somewhere in September or even earlier. If yes, I would ask > James to prepare the patch for core.filesystem too. Just to say that if you ever need to know at a glance where the branch point was, you can look at: http://github.com/jamesblackburn/eclipse-core-filesystem/network This shows the last common commit on 7th Oct by JohnA. You should be able to pick a date spec anywhere between 7th and 16th to perform your 3-way merge in Eclipse. The slightly worrying thing about CVS is the lack of repo locking and consistency checking. So if someone was committing during a fork or tag, the results of the 3-way merge might be 'interesting'. I've noticed some brokeness in some of the original history in the org.eclipse.ui.ide repo - some of the image files have tagged versions which don't actually exist in the repository. e.g.: CVSROOT=:pserver:anonymous@dev.eclipse.org:/cvsroot/eclipse cvs rlog org.eclipse.ui.ide/icons/full/etool16/new_wiz.gif what happened to the version pointed at by v20040316?
(In reply to comment #39) > Yes, that's a very good idea. This is probably obvious, but these tags should > be in the 3.x repo as it's the reference point for the next 3-way merge. In the 3.x repo, a single tag will suffice sine it's not being changed as part of the merge: MERGE_to_e4_0.9m2 wheres in the e4 repo, separate tags before and after the merge make sense: BEFORE_3.5m6_MERGE MERGED_3.5m6 (or: e4-root-3.5m6-merge) a common naming convention for these kinds of tags makes sense ("MERGE_to",...)
(In reply to comment #38) > Created an attachment (id=129394) [details] > core.filesystem.patch > > (In reply to comment #33) > > I think it was somewhere in September or even earlier. If yes, I would ask > > James to prepare the patch for core.filesystem too. > > Attached. No conflicts during the merge. > Both core.filesystem and core.contenttype patches looks good. Isn't it the right time to commit them all, if we want to be on time for m2?
I was thinking about the right time to sync e4 with 3.x. In 3.x, we do integration builds on Tuesdays. I think that we should use plug-ins in versions from those IBuilds. This would prevent us from merging not tested changes. So the steps would be: 1) Wait for IBuild in 3.x 2) If IBuild is ok and tests are green, take plug-ins in versions from the IBuild 3) Merge them into e4 and remember the last used versions or just tag the plug-ins in 3.x I can handle resources plug-ins.
Created attachment 129430 [details] org.eclipse.ui.ide patch2 Fix unresolved conflict in ResourceInfoPage.java file header comment...
(In reply to comment #43) > Both core.filesystem and core.contenttype patches looks good. Isn't it the > right time to commit them all, if we want to be on time for m2? Yes! Go for it !!!
The following patches are now committed to the e4 resource plugins repository and released as of v20090320-1130: org.eclipse.ui.ide patch2 ore.filesystem.patch core.contenttype.patch org.eclipse.core.tests.resources org.eclipse.core.resources.patch
