Bugzilla – Full Text Bug Listing
| Summary: | You can only copy from left to right in Compare Editor | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Davy Meers <davymeers> |
| Component: | Mylyn | Assignee: | Project Inbox <mylyn.intent-inbox> |
| Status: | CLOSED MOVED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
Davy Meers
You're absolutely right. Merging changes from left (the document) to right (the model) already works as it is a basic application of EMFCompare. Merging changes from right (the model) to left (the document) is less straightforward, and some important choices have to be made : let's take your example. In your intent document, the EClass Database is not defined but it is in the model. When you merge changes from right to left, what do you expect Intent to do : (1) Add the Database definition inside the EPackage which contains it (2) Add the Database definition inside a new modeling unit that contribute to this EPackage Both solutions are not satisfying : (1) forces you to document your EClass at the same place as the EPackage (which is exactly what we do not want to do with Intent) and in (2) we don't know where to create the new modeling unit. What I propose is that each intent document contains a "special" hidden chapter called "Non document elements", that you cannot see in the arborescence and cannot edit manually. This chapter will contain all modeling units created automatically when merging changes from model to document (solution (2)). So when you merge changes from model to document, you will not have synchronization issues any more as the model is defined in your documentation, but you'll get "non documented" warnings as no documentation is associated to these elements. A new view called "Non document Element" would list all elements that are defined in this chapter. With a simple drag and drop from this view inside an intent editor, a new modeling unit describing only the element you've dropped (whether it's the Database EClass or only one of its attributes) will be created. I think this mechanism has 2 main benefits compared to (1) or (2) : - when merging changes from model to documentation, you are totally free to choose where the merged elements should be documented (inside an existing section ? inside a new section ?). - when merging changes from model to documentation, you are totally free to document only sub-parts of the model and not the entire models. One can imagine that the "non documented" warnings could be customized : for instance you can say "an EClass should always be documented, but not an EAttribute". Which would mean that if you have an EClass in the "non documented elements" view you'll get a warning, but not if you have only EAttributes. This could be great for retro-documenting existing models or projets : you first make a big merge from workspace to documentation, that would create all the modeling units inside the "non document chapter". Then you fix the "non documented" warnings step by step, creating the documentation. What do you think about this solution ? It is now clear to me that automatically merging from right to left makes little sense. What you propose seems a nice solution to me. In addition to the "Non document element" view you could also offer the option in the content assist to "Add a non-documented element". Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn |