Community
Participate
Working Groups
In order to associate tasks and builds with change sets a generic data model is needed that provides an abstraction for SCM changes. The data model should be extensible to allow connectors to supply a data model specific to a particular SCM system.
I have committed a first pass at this based on the data model of the builds framework. The plug-ins are in CVS: sandbox/org.eclipse.mylyn.scm.core sandbox/org.eclipse.mylyn.scm.ui
Created attachment 179497 [details] mylyn/context/zip
Created attachment 181329 [details] model
Created attachment 181337 [details] team project set
I have added an implementation for cvs that is capable of retrieving a single revision of a file from a repository but it does not have any change set support, yet (bug 326115). The attached picture shows the structure of the proposed data model abstraction. Note that the classes that I committed to CVS were not actually generated from the model but was implemented from scratch. I am not sure whether having an EMF model makes sense for the SCM framework since the data model is fairly simple and providing proper synchronization is more challenging with generated code. The goal is that the model delegates to classes in the team API as much as possible and only provides a thin wrapper around existing APIs. My hope is that we can keep the model and API fairly simple that way.
Created attachment 181464 [details] alternative model Hi Steffen, the model looks good, but i don't quite get, why there are 2 one to many relationships between Changeset, Change and ChangeArtifact. In case of CVS, the there would be only one ChangeArtifact per Change and multiple Changes per Changeset, while in subversion there would be multiple ChangeArtifacts per Change, but only one Change in each Changeset. Is that correct? If it is, I would recommend to remove on class from the model. I've attached the SCM model, that would be pretty straight forward for CVS; for subversion the model would have redundant fields, but this can be solved by having a ChangeArtifact implementation, which does not persist that information, but rather delegate that to the ChangeSet. As it's a bit hard to explain, I've included a sample implementation for subversion in the model too.
Thanks for the feedback. ChangeSet might indeed be superfluous for the core model. It groups multiple changes from a single repository but this could indeed be simplified. (In reply to comment #6) > In case of CVS, > the there would be only one ChangeArtifact per Change and multiple Changes per > Changeset, while in subversion there would be multiple ChangeArtifacts per > Change, but only one Change in each Changeset. Is that correct? For CVS, there would be one ChangeSet with one Change and then a ChangeArtifiact per revision associated with a particular commit. The Change.revision field would always be null for CVS since CVS tracks revisions on a per artifacts basis. For Subversion, there would be one ChangeSet with one Change that represents a revision and then a ChangeArtifiact per file in that revision. > I've attached the SCM model, that would be pretty straight forward for CVS; for > subversion the model would have redundant fields, but this can be solved by > having a ChangeArtifact implementation, which does not persist that > information, but rather delegate that to the ChangeSet. As it's a bit hard to > explain, I've included a sample implementation for subversion in the model too. The proposed changes make sense to me but I would keep message and revision on ChangeSet since that is closer to the abstraction that we are looking for.
As discussed in the call today: -Move message to the Change/Changeset -Change/ChangeSet should also has a Revision field but named id to avoid confusion. -The author relationship should not be from the ChangeArtifact but from the Change/ChangeSet.
Created attachment 181895 [details] updated model
I have committed the changes as discussed to CVS. Kilian, let me know if there are other changes that I missed.
I'll mark this as resolved and we can open new bugs to track further changes.
