(v3) Reloading RwProject after checking out different branch checks out previous branch

[ericwinger]

My reproduction case is in Jadeite but I suspect that it could be reproduced in topaz:

• Load RowanSample1 from sample_V2 branch
• On disk, checkout a different branch. (I created a temp branch)
  git status should show the other project checked out.

ewinger@uffda:/uffda1/users/ewinger/rowanStones/checkouts/gemstone37rowanv3_externals_st/RowanSample1$ git checkout temp
Switched to branch 'temp'

• send reload to the RwProject for RowanSample1
• Do a git status on a command line to see the other branch checked out.

ewinger@uffda:/uffda1/users/ewinger/rowanStones/checkouts/gemstone37rowanv3_externals_st/RowanSample1$ git status
On branch sample_v2
Your branch is up to date with 'origin/sample_v2'.

This seems to be a bug. If this is intended behavior, it's quite surprising and not intuitive.

[dalehenrich]

looks like a bug ...

there are certain circumstances where switching branches is desired (resolveStrict), but this issue doesn't smell like that particular circumstance ...

the other fishy bit is that the RowanSample1 load spec for sample_V2 does have a revision specified (sample_v2), and there are certain operations that could trigger a switch branch and that is probably the situation that you're running into here ... definitely not expected,...

If you are handling a RwAllowChangeRepositoryRevisionOnResolveNotification and resuming with true, then this would be expected behavior for RowanSample1 ...

Finally, it doesn't look like there any Rowan tests that play with RowanSample1, so a regression with respect to RowanSample1 specs would not be surprising ... no tests using RwAllowChangeRepositoryRevisionOnResolveNotification, either ...

I see that Jadeite has RowanSample1 tests, but up until now(?) they weren't wandering into "unknown territory"

... and of course when I get to fixing this bug, I will add more test coverage in this area ...

[ericwinger]

If you are handling a RwAllowChangeRepositoryRevisionOnResolveNotification and resuming with true, then this would be expected behavior for RowanSample1 ...

To my knowledge no notifications or warnings were raised.

[dalehenrich]

#reload should use the loadedLoadSpecifications;read:;load sequence

[dalehenrich]

With the recent changes to the #reload implementation (0a0a7f1), this problem does not appear to reproduce:

JadeiteForPharo ce29551
PharoGemStoneFFI 3575de4
RemoteServiceReplication 371ae8e
---------------------------------------------
RowanClientServices ef59884
RowanV3 0a0a7f184

fixed by Issue #926