|
|
| Re: [EMF][EMFStore][Sirius] Change Operations and graphs [message #1591562 is a reply to message #1587777] |
Thu, 29 January 2015 16:00  |
 Maximilian Koegel
Messages: 253
Registered: July 2009 |
Senior Member |
|
|
Hi Alain,
I will try to answer your questions inline...
> The way that changes are recorded seem to be to record every operation
> happening during the session and not only to have a list of operations
> that represent the diff at save time. This would be akin to a VCS
> recording every keystroke instead of just a delta at commit/save time.
This is correct, every change on the model is recorded as one operation.
If you have a databinding which writes to the model on every keystroke
it potentially means every keystroke is recorded as an operation. You
could avoid this by changing the update policy in the databinding.
Nevertheless EMFStore will record every change you do one the model
while you change the model. This is fundamentally different from e.g.
EMFCompare which derives the changes after they have been performed.
Maybe this documentation can help clarify how things work in EMFStore
and why:
http://eclipsesource.com/blogs/tutorials/emfstore-versioning-history-and-branching/
There is advantages and drawbacks to both - change-based/operation-based
Versioning (EMFStore) and state-based Versioning (EMFCompare).
> Anyway, we end up with thousands (and tens of thousands) of operations
> when generating diagrams or when a user does some layouting. Layouting
> is the worst culprit for creating floods of operations. We understand
> that diagram by their very nature will create a much larger number of
> operations, but here it is multiplied to the extreme.
> On the pure EMF side, we see that the change recorder make a list copy
> on every change and this is done with resolving list which forces a scan
> of all elements which get progressively slower and drags the application
> as the pool of operation grows. Can't this be improved by avoiding
> constant list copies or trying to resolve (we see no real resolution
> going on)?
Yes, it could be. Currently the implementation of the operation list is
based on EMF. Changing it to an optimized list for this purpose would
definitely speed up things significantly. Maybe this is a contribution
you could make or you could sponsor an open-source implementation.
> Next why is it necessary to capture every operation and not only to
> capture a final delta?
This is related to operation-based versioning as mentioned above. I know
of non-open-source extensions to EMFStore which later consolidate the
list of operation by canonizing multiple related changes into one, but
there is no open-source solution to my knowledge at this point.
> How are diagrams like Sirius / GMF working for others in an environment
> like EMFStore that tracks all changes like this?
We have customers using huge diagrams with EMFStore. Mostly they use
composite operations to wrap all the small operations related to a
diagram change into one composite operation. Nevertheless there will be
many small operations in the composite. It just helps with atomicity in
conflict detection/merging and with visualization.
> On a side note, when committing such change sets with tens of thousands
> of operations describing how you re-arranged a couple of diagram, the
> commit information looses all its value, can it be grouped so that it
> can be made meaningful?
See my comment above. With composite operations you can make
visualization a lot more compact and usable.
Hope this helps a bit! ;)
Cheers,
Maximilian
>
> Thanks
> Alain
>
>
--
Maximilian Kögel
Get professional Eclipse developer support:
http://eclipsesource.com/en/services/developer-support/
|
|
|
Powered by
FUDForum. Page generated in 0.03390 seconds
] 
Search
Help
Register
Login
Home
