Community
Participate
Working Groups
Build Identifier: Currently there is no API to get the differences between two branches. Please provide an API to get the differences between two branches. As a workaround one can today create a fake merger that does not merge and access the differences from there: class FakeMerger implements CDOMerger { public CDOChangeSet target; public CDOChangeSet source; @Override public CDOChangeSetData merge(CDOChangeSet target, CDOChangeSet source) { this.target = target; this.source = source; // return null, and therefore do NOT do an actual merge return null; } }; FakeMerger fakemerger = new FakeMerger(); CDOTransaction mergetransaction = transaction.getSession().openTransaction(testbranch); mergetransaction.merge(mainbranch.getHead(), fakemerger); mergetransaction.rollback(); Reproducible: Always
I would also be great if the API supported a diff between a historic model state and a branch. For example, what changed since 3/1/2010 for branch foo. Another example, what's the diff between branch foo at 3/1/2010 and MAIN today.
Created attachment 185493 [details] Patch v1
Created attachment 185494 [details] Patch v2
Committed to HEAD
Does not work correctly, yet...
As collecting the diff is most likely a long running operation, would it make sense to pass in an optional IProgressMonitor?
New API: CDOChangeSetData CDOSession::compareRevisions(CDOBranchPoint source, CDOBranchPoint target); CDOChangeSetData CDOView::compareRevisions(CDOBranchPoint source); CDOTransaction CDOSession::openTransaction(CDOBranchPoint target, ResourceSet resourceSet); CDOTransaction CDOSession::openTransaction(CDOBranchPoint target); CDOView CDOSession::openView(CDOBranchPoint target, ResourceSet resourceSet); CDOView CDOSession::openView(CDOBranchPoint target);
(In reply to comment #1) > I would also be great if the API supported a diff between a historic model state > and a branch. For example, what changed since 3/1/2010 for branch foo. Another > example, what's the diff between branch foo at 3/1/2010 and MAIN today. All of these should work. Tests in org.eclipse.emf.cdo.tests.CompareTest.
(In reply to comment #6) > As collecting the diff is most likely a long running operation, would it make > sense to pass in an optional IProgressMonitor? I hesitate to add IProgressMonitor to our API a second time.
Usually you'd schedule the compareRevisions() call to a background thread anyway.
(In reply to comment #10) > Usually you'd schedule the compareRevisions() call to a background thread > anyway. That's true, but it might still be nice to know how far along it is (if that information is available). Oh, and I did not quite understand the comment #5 (what second time?)
I was referring to CDOTransaction.commit(IProgressMonitor). Since CDO is supposed to run outside of Eclipse that turned out as a poor choice.
I se(In reply to comment #12) > I was referring to CDOTransaction.commit(IProgressMonitor). Since CDO is > supposed to run outside of Eclipse that turned out as a poor choice. I see. Well you could create your own version of a ICDOProgressMonitor that allows an easy adaption for eclipse users like IProgressMonitor monitor = //get the Eclipse monitor transaction.commit(new CDOProgressMonitor(monitor)); that way you can support progress monitors that are eclipse independent.
We have that in Net4j: OMMonitor / EclipseMonitor ;-)
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
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.
