Hi
If I've got something good that has significant conflicts with
master
Check out somethingGood.
Reset mixed to master.
Review GIT changes
If the changes are substantial, partition into themes, and select
all changes for one theme, commit, test. Repeat till done.
If whitespace/reordering changes have crept in, it can help to
adjust somethingGood to avoid the confusing aesthetic chnages until
the important functional changes are resolved.
Reducing the number of auto-generated files that participate in GIT
commits also simplies what needs checking.
It's a pain, but it seems the only way of catching the subtle XML
file chnages.
-----
ewillink/mtc4 removes some irregular code in QVTp2QVTg whose sole
purpose now seems to be in preventing oclContainer() working. With
the extra commit, Example 4 can use oclContainer() or oclContainer.
-----
Beware of reviewing related multi-test results. If xxxExample4_YYY
follows xxxExample4_ZZZ a failure in xxxExample4_YYY may be due to
dirty registrations left behind by xxxExample4_ZZZ. Assess failures
individually, then resolve the inter-test registration corruptions.
On 22/12/2015 10:59, Adolfo
Sanchez-Barbudo Herrera wrote:
Hi Ed,
Comments in-line below.
Regards,
Adolfo.
On 22/12/2015 08:26, Ed Willink wrote:
Hi
The major problem is the plugin.xml registrations. These are
useful to publish installed models and StandaloneProjectMap
observes them in standalone contexts. However such declarations
in JUnit tests are counterproductive leading to fights between
any installed versions and development versions. They also
clutter a nested Eclipse with unwanted models. Particularly bad
when nsURIs / qualifiedClassNames are not unique. Therefore test
plugins should not declare models. Instead I added InstallMap to
add/remove the declarations in each test. The genmodel needs at
least "PluginKey" to be blank to avoid corrupting plugin.xml on
regeneration.
Ok.
Since oclContainer is a navigation, it was much easier to model
it as a Property in the new scheduler. OCLstdlib now provides
both oclContainer() and oclContainer. oclContainer works for
Example 4. I'll look at supporting oclContainer().
See ewillink/mtc4.
Your rebase involves nearly 400 files, almost as many as I had
to resolve for the new scheduler integration.
It is very hard to review these changes accurately.
Perhaps it's hard, but rebasing the same conflicting files changed
in many different commits is a nightmare, as of current EGit
tooling. I had to squash them together to do a sensible/more
consistent rebase.
I suggest pursuing a similar policy as I adopted. Flatten all
the changes and re modularize. Divide and conquer. One commit
for Example 5. One for Example 4. One for ... in an order where
you can test each for success. Bigger easy commits first. With
smaller commits, checking for bad conflict resolution as in the
*.genmodel, plugin.xml is much more tractable. You will also
avoid a confusing history that makes and then retracts changes
to e.g. plugin.xml.
If you are suggesting to split a big commit into many, I'm unsure
how to do that. Perhaps, doing a soft reset after rebasing the big
commit ?. I'll have a look at google.
You will probably find it helpful to avoid reordering in
OCL2QVTiTestCases.java or whitespace cleanup in MtcBroker.java
until an update is complete. You will need to do many GIT
Complete Trees and so want to minimize obfuscation.
Regards
Ed
On 22/12/2015 06:57, Ed Willink
wrote:
Hi
On 21/12/2015 16:13, Adolfo
Sanchez-Barbudo Herrera wrote:
- All new scheduler test cases fail. Perhaps a trivial fix,
but I've not looked into it to discover what is cause the
test to fail. Example 2 has changed, but that was not a
problem for the flat scheduler. Example 4, had a minor
rework in the CS2AS description (apart from fixing the
Node::depth feature name).
I'll look at Example 4.
Regards
Ed
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev
_______________________________________________
qvtd-dev mailing list
qvtd-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvtd-dev
|