[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [qvto-dev] QVTo Examples Integrity
|
Hi,
Merging master into parallel branch every milestone, makes sense to me.
Providing that some QVTo branch code can contribute something useful to
master, if it depends on some OCL non-master branch, the QVTo branch
code can't be merged into master till the OCL one does.
Cheers,
Adolfo.
On 01/09/2014 14:15, Ed Willink wrote:
Hi
Until recently, I have been advocating always-rebase/cherry-pick and
never-merge for GIT.
This seems sensible for short sharp developments (a couple of weeks),
but it works really badly for a concurrent development that spans
multiple milestones. So if for instance a contribution starts at M1 and
gets rebased at M4 then; either all commits at M1/M2/M3 are revisited to
be compatible with the prevailing state of the system at M4, or the
commits are not revised.
Revising the commits can take quite some time and is of dubious utility.
Auto-generated code can be really hard to revise.
Not revising the commits means that anyone who checks out one of the
rebased commits will have difficulty understanding errors from code
developed at say M2, but rebased on M4.
So for long term developments, my recommendation is to merge with master
at least every milestone. By merge with master, I mean that the ongoing
development branch comprises development and master code. I do not mean
that master comprises the interim development code and a new development
branch starts. I see little point in putting WIP onto master until it
actually contributes something useful, but put it there just as soon as
it does.
Regards
Ed Willink
On 01/09/2014 13:08, Adolfo Sanchez-Barbudo Herrera wrote:
Hi Ed,
It sounds OK to me.
That means that either OCL wip code branches are frequently integrated
into master, or QVTo wip would have to go to its master-independent
branch (which we had agreed to avoid, since QVTo wip code was not
integrated into builds). I guess that the former is not realistic, and
the latter is more sensible anyway... so from now on, I'll work in a
separate branch.
Regards,
Adolfo.
On 01/09/2014 12:45, Ed Willink wrote:
Hi
The guys from Nspyre/ASML are starting to look at exploiting the OCL
pivot model for QVTo evaluation; welcome.
They have spotted that the integrity of some of our work in progress
commits is imperfect so I've just pushed four commits to remedy the
problems.
I think two of the problems were that OCL generation framework
refactoring were not propagated to QVTo and a further two by not using
the OCL master as the reference for commits to QVTo master.
Adolfo: I just deleted the AutoLookupVisitor code, pending resolution of
dependencies.
Anyway, from now on with some real users, we must ensure that the
non-obsolete examples plugins are always error free with respect to the
most recent EMF/UML/OCL/Xtext milestone, and that work in progress has
no adverse effect on useful functionality.
Regards
Ed Willink
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2014.0.4745 / Virus Database: 4015/8134 - Release Date: 09/01/14
_______________________________________________
qvto-dev mailing list
qvto-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/qvto-dev
