I've committed one more fix that should make things right on 2.8.3.
Tim
On Wed, Feb 16, 2011 at 8:16 PM, Tim Moore <timoor...@gmail.com> wrote:
> OK, I see that merely removing the 2.8.3 case from my conditional,
> which I checked in a couple of hours ago, isn't correct. I'll have
> another go.
>
> On Wed, Feb 16, 2011 at 7:10 PM, ThorstenB <bre...@gmail.com> wrote:
> > On 15.02.2011 13:41, Tim Moore wrote:
> >> I've checked in fixes for this change in osgDB:DatabasePager to the
> >> SimGear and FlightGear next and releases/2.2.0 branches.
> > Still doesn't compile with OSG <= 2.8.5. We also need the patch that
> > Bertrand sent yesterday, i.e. the "#ifdef" logic for the
> > "_readerWriterOptions" attribute is still incorrect (inverted):
> >
> > diff --git a/simgear/scene/model/SGPagedLOD.hxx
> b/simgear/scene/model/SGPagedLOD.hxx
> > index a9e55d9..4e25931 100644
> > --- a/simgear/scene/model/SGPagedLOD.hxx
> > +++ b/simgear/scene/model/SGPagedLOD.hxx
> > @@ -72,7 +72,7 @@ public:
> >
> > protected:
> > virtual ~SGPagedLOD();
> > -#if SG_PAGEDLOD_HAS_OPTIONS
> > +#if !SG_PAGEDLOD_HAS_OPTIONS
> > osg::ref_ptr<osgDB::ReaderWriter::Options> _readerWriterOptions;
> > #endif
> > };
> >
> > => Fixes the compile for any OSG version without
> > "SG_PAGEDLOD_HAS_OPTIONS" support.
> >
> >> By the way, I committed the changes to releases/2.2.0 and then merged
> >> that branch into next. This is the way fixes should move between the
> >> two branches. Please don't commit a fix to next and then cherry-pick
> >> it to the release branch. It is very messy to have the same change
> >> committed on several different branches.
> >
> > Hmm. On the other hand this means applying all (experimental) patches to
> > the stable release/2.2 branch first.
> > I'm not a git expert, but generally I like the opposite approach of
> > applying patches to a project's experimental ("master" / "next" / ... )
> > branch first. And only after the patch proved to be ok and stable for
> > everyone, eventually move it to the stable release branch. Reduces the
> > risk of (temporarily) breaking a release branch (like we did now :) ).
> Well, in this case I should have tested with 2.8.3, which I don't
> happen to have checked out. Anyway, we chose a simple branching model,
> http://nvie.com/posts/a-successful-git-branching-model/ , where fixup
> work done on the release branches is merged into the development
> branch. It is very messy to have a commit "virtually" checked in on
> several different branches. As there is no good reason for the
> development branch not to have all the commits made to the release,
> the commits should originate on the release branch and be merged into
> development.
>
> Now, you don't have to work this way locally, and in this case I
> didn't; I had next checked out, so hacked away on a fix and committed
> it locally. I then rebased that fix onto the release branch, tested
> (hah!), committed that and pushed it to gitorious. I then reset the
> next branch to blow away my commit at the head, merged in
> releases/2.2.0, and pushed that. You can use "git rebase" to get
> things in shape before committing to the master repo in the way I've
> described.
>
> Tim
> >
> > cheers,
> > Thorsten
> >
> >
> >
> ------------------------------------------------------------------------------
> > The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> > Pinpoint memory and threading errors before they happen.
> > Find and fix more than 250 security defects in the development cycle.
> > Locate bottlenecks in serial and parallel code that limit performance.
> > http://p.sf.net/sfu/intel-dev2devfeb
> > _______________________________________________
> > Flightgear-devel mailing list
> > Flightgear-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> >
>
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
