Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 354590

Summary:	History for containment trees
Product:	[Modeling] EMFStore	Reporter:	Andre Boehlke <ab>
Component:	Common	Assignee:	Maximilian Koegel <mkoegel>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	normal
Priority:	P3	CC:	emueller, mkoegel
Version:	unspecified	Keywords:	needinfo
Target Milestone:	backlog
Hardware:	PC
OS:	All
Whiteboard:

Description Andre Boehlke

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

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

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

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

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

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

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

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

2016-03-02 04:32:25 EST

Closing because of inactivity. Please re-open, if applicable, or create a new BR.