Re: [qvto-dev] QVTo Examples Integrity

[Ed Willink <ed@xxxxxxxxxxxxx>]

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