Community
Participate
Working Groups
Build Identifier: Starting from source branch S and target branch T, we do a full promote on a model object graph like this: CDOBranch sourceBranch = getSourceBranch(); CDOBranch targetBranch = getTargetBranch(); CDOTransaction transaction = createTransaction(targetBranch); CDOMerger merger = new DefaultCDOMerger.PerFeature.ManyValued(); CDOBranchPoint sourceHead = sourceBranch.getHead(); CDOChangeSetData merge = transaction.merge(sourceHead, merger); transaction.commit(); This works fine on the first try: when S contains a model and T doesn't contain anything. The first merge/commit successfully copies S into T. (Note: I have applied https://bugs.eclipse.org/bugs/show_bug.cgi?id=336532 locally to resolve the MySql merge issue) However, when I make incremental changes to S and then try to promote those changes T using the above code, nothing happens. Furthermore, when I dump the contents of the CDOChangeSetData that results from the merge, it has no changes in it. Reproducible: Always
Looking into this further, I'm wondering if this related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=333058.
Additional information: When I do: CDOChangeSetData compareRevisions = transaction.compareRevisions(sourceHead); in the same context as the above, the resulting CDOChangeSetData *does* contain the changes I expect. What I really want to do is the equivalent of taking that CDOChangeSetData and merge/committing it to the target branch.
Cameron, have you tried to use the newer merge() method that has two CDOBranchPoint methods?
(In reply to comment #3) > Cameron, have you tried to use the newer merge() method that has two > CDOBranchPoint methods? Yes, but so far whatever "sourceBase" I try to use throws an exception that it is not "contained". There's also no documentation on it and it wasn't clear how I was supposed to determine what sourceBase to use in the arbitrary case.
Created attachment 191295 [details] applyChangeSetData patch Hi Cameron, I don't know how your branches are structured, but "not contained" exception occurs when trying to merge a branch to another branch, that is not the ancestor of the branch. (E.g. when creating a branch from MAIN, you can merge the changes back from the branch to MAIN, but not the other way around). We had problems with merging as well, e.g. once the merge is already done, when the changes are applied, all the changed objects will be compared again, which takes a lot of time when comparing objects with large list. We have created our own applyChangeSetData method (see attachment), that applies an arbitrary change set data to the transaction, thus it can be used to promote changes from one branch to another. We are using the commit infos to compute the change sets on the branch (CDOSesion.getCommitInfoManager().getCommitInfos). On the other hand you can still use CDOMerger.merge to see whether there are conflicting changes. Eike, it would be fine if you could review this patch, whether it makes sense and usable under some circumstances. In our case the merging of branches became much faster, and there were no problems with incremented changes.
(In reply to comment #5) > I don't know how your branches are structured, but "not contained" exception > occurs when trying to merge a branch to another branch, that is not the > ancestor of the branch. IIRC this exception can only occur if the newer merge() method with the sourceBase branchpoint is used. Then the sourceBase point must be reachable by traveling up from the source point to the MAIN branch. I.e. sourceBase must be a baseline of source. The meaning of the merge is then: Merge all changes that happened between sourceBase and source into the current branch of the transaction. With this method the issue of duplicate objects/changes for remerges with the single branchpoint merge() method are addressed. > Eike, it would be fine if you could review this patch, whether it makes sense > and usable under some circumstances. In our case the merging of branches became > much faster, and there were no problems with incremented changes. I would definitely like to look at it! I'll return from the EclipseCon after end of March and I have a bugzilla backlog of 28 now. Please don't expect that I'll find time before begining to mid of April ;-(
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
We'll try to address open problems in 4.3 (master) first and then port fixes back to 4.2.
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
Moving to 4.13.
