Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 354590 - History for containment trees
Summary: History for containment trees
Status: CLOSED WONTFIX
Alias: None
Product: EMFStore
Classification: Modeling
Component: Common (show other bugs)
Version: unspecified   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: backlog   Edit
Assignee: Maximilian Koegel CLA
QA Contact:
URL:
Whiteboard:
Keywords: needinfo
Depends on:
Blocks:
 
Reported: 2011-08-12 04:41 EDT by Andre Boehlke CLA
Modified: 2016-03-02 04:32 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andre Boehlke CLA 2011-08-12 04:41:16 EDT
Hello,

this is a feature request.

I would like to get the HistoryInfo/ChangePackage for an arbitrary model contained in a project. Like in SVN, where each file in a project (repository) is versioned seperately.

Regards,
André
Comment 1 Maximilian Koegel CLA 2011-08-12 06:01:57 EDT
Hi André,

thanks for your request. Just to check, if I understand correctly: you would like to be able to retrieve Changes and History for a EObject and its containment tree, correct? What about objects that have at some point belonged to this containment tree but that do no longer belong to it (as seen from the current head revision)?

Cheers,
Maximilian
Comment 2 Andre Boehlke CLA 2011-08-12 07:22:29 EDT
Hi Maximilian,

that's right: I would like to see changes in the containment tree of a given EObject. If an EObject is removed from the containment tree, I would expect that change to be represented by a SingleReferenceOperation in the history of every containing EObject.

AFAIK, the Project's cutElements containment reference holds all the EObject orphans, right? So technically, every EObject can still be referenced by old ChangePackages/AbstractOperations.

Regards,
André

(In reply to comment #1)
> Hi André,
> 
> thanks for your request. Just to check, if I understand correctly: you would
> like to be able to retrieve Changes and History for a EObject and its
> containment tree, correct? What about objects that have at some point belonged
> to this containment tree but that do no longer belong to it (as seen from the
> current head revision)?
> 
> Cheers,
> Maximilian
Comment 3 Maximilian Koegel CLA 2011-08-12 08:07:13 EDT
Hi André,

This seems quite feasible. I would suggest the following behavior and implementation: The client will need to derive all elements that are part of the containment tree (e.g. based on the current revision). It will send all model element ids that are part of the containment tree to the server, the server will then return all Operations that are involved with any of these ids. This would also contain the ReferenceOperations of detached objects as you point out in your example.
BTW, the cutElements containment reference is just a temporary storage for cut elements it is cleaned on every workspace start-up and objects are permanently removed then (deleted).

Cheers,
Maximilian

(In reply to comment #2)
> Hi Maximilian,
> 
> that's right: I would like to see changes in the containment tree of a given
> EObject. If an EObject is removed from the containment tree, I would expect
> that change to be represented by a SingleReferenceOperation in the history of
> every containing EObject.
> 
> AFAIK, the Project's cutElements containment reference holds all the EObject
> orphans, right? So technically, every EObject can still be referenced by old
> ChangePackages/AbstractOperations.
> 
> Regards,
> André
> 
> (In reply to comment #1)
> > Hi André,
> > 
> > thanks for your request. Just to check, if I understand correctly: you would
> > like to be able to retrieve Changes and History for a EObject and its
> > containment tree, correct? What about objects that have at some point belonged
> > to this containment tree but that do no longer belong to it (as seen from the
> > current head revision)?
> > 
> > Cheers,
> > Maximilian
Comment 4 Andre Boehlke CLA 2011-08-12 14:10:26 EDT
(In reply to comment #3)

Hi,

sorry, I don't understand. Why would I have to give the server more than one model ID to get a recursive ChangePackage?

Regards,
André
Comment 5 Maximilian Koegel CLA 2011-08-15 05:47:11 EDT
Hi,

the client framework would do it not the developer using the API. In the API the developer could query the history for a given model element in a project. The API would then assume the element´s current version to be the reference version to determine the elements that are children of the given element and query the server for a cumulative history of the derived set of elements (given element and its children in the current version).

Cheers,
Maximilian

because it (In reply to comment #4)
> (In reply to comment #3)
> 
> Hi,
> 
> sorry, I don't understand. Why would I have to give the server more than one
> model ID to get a recursive ChangePackage?
> 
> Regards,
> André
Comment 6 Andre Boehlke CLA 2011-08-16 10:58:42 EDT
(In reply to comment #5)

Hi Maximilian,

thank you for investigating this case!
We require a complete history for an object, not just the currently contained descendants. The User need to see all changes which were made in the hierarchy of an object. Like in SVN.

I will open a new bug for our use case.

Regards,
André
Comment 7 Eclipse Genie CLA 2014-05-16 11:10:41 EDT
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet.

If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.

--
The automated Eclipse Genie.
Comment 8 Edgar Mueller CLA 2016-03-02 04:32:25 EST
Closing because of inactivity. Please re-open, if applicable, or create a new BR.