Hi, Philip,
We had, in early releases, editor window layout information in the *.di file that caused headaches of constant churn and conflicts in that file in team source control (note that it is still an option to do this, which is useful when sending models to others with diagrams already open to show them). This was a problem because the editor layout is a manifestly personal thing, user-specific information that normally should not be shared. What you propose is not like this, so that is good. However, I think I would prefer not to see this index in the *.di file mostly because it is derived information. It is like the compiled *.class files and other resources that the Eclipse workspace treats specially: it is computed from the information already in source control and so keeping it there is redundant. But also this *.di resource can contain non-derived user data, so it cannot be excluded from source control (some users may like to) and it cannot be somehow treated as partially derived. And what are the potential pitfalls for team scenarios? I can imagine cases where merge accidents corrupt these indices, for example, if done without the EMF Compare tooling to manage it carefully. I would prefer to keep the index in the workspace metadata. I don’t think that the start-up cost for a new workspace of indexing the models is so onerous, but I must admit that I haven’t ever had the opportunity to observe it on real-world models of very large scale, only with naïvely generated models.
Will your alternative solution require adding to the workspace metadata an index of all of the model files in remote branches that the user has fetched? Would this be so different to discovering an index that is stored within those same files?
I hope that mine is not the only opinion on this subject.
On 25 November, 2016 at 12:57:11, Philip Langer (planger@xxxxxxxxxxxxxxxxx) wrote:
Hi,
in the context of diff/merge with EMF Compare and
EGit, I'm currently analyzing the potential usage of the new
cross-reference index [1] for resolving the "logical model" that
may span across many file resources.
So far things are looking good in my prototype for the
workspace side. This new API is very well done and easy to
integrate! However, the real challenge for me will obviously be the
indexing on the remote/origin side in the repository storages.
Thus, my next step will be to check whether I can extend the
OnDemandCrossReferenceIndex so it'll be able to resolve the
cross-references on other branches of the repository (i.e., not the
workspace, but not-checked out branches).
Before I continue with that however, I wanted to get your
opinion on another option. What do you think about storing the
cross-reference index in the di-files? Instead of storing the index
in the workspace .metadata (as it is now, I suppose), we could
store them on-save in the respective di-files.
This would make it faster when someone opens a model the first
time in his/her workspace, as the index could be initialized from
the di-files, and it would make it very easy to determine the
logical model on remote/origin sides in the context of diff/merge
with repository providers, such as EGit. Instead of building up an
index on the not-checked-out branches, we could just obtain the
di-files and read the cross-reference index from there.
Please let me know what you think and whether this could be an
option. Because if yes, it might then be unnecessary to work on an
extended CrossReferenceIndex implementation for not-checked-out
branches.
Thanks a lot for your opinions and best wishes,
Philip
_______________________________________________
mdt-papyrus.dev mailing list
mdt-papyrus.dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/mdt-papyrus.dev
|