checkpoint Issue #43

getting started on issue #43
methodProperties.json are from mistake in upgrading FileTree...
checkpoint Issue #43

getting started on issue #43
methodProperties.json are from mistake in upgrading FileTree...
Issue #43 : another spot needing `currentVersion` lookup

The previous commits implemented the basic `prime registry` algorithm,
however, during tests, I discovered that a load of Metacello (with
registry primed) was trying to incorrectly downgrade/upgrade some
dependent packages, in both `classic` and `new` modes.

The first-order problem was that using `ignoreImage` to signal `classic`
mode was a mistake. `ignoreImage` causes some fundamental load changes
over and above what I was looking for when I first decided to use it.

`ignoreImage` has been exposed as a normal option (no longer hidden).

I added `useCurrentVersion` option (hidden) to implement the `classic`
mode.

In addition, it turns out that the logic in MetacelloMCProjectSpec>>compareCurrentVersion:targetVersionStatus:using:
needed to do a #currentVersion lookup. Arranged for
AllowDowngrade/AllowUpgrade exceptions to be thrown so that the user can
exert control.

The initial test case that exposed this issue is now functioning
correctly ... need to run test suite (thank you travis) and consider
adding additional tests.
Save new version of configuration to pick up MetacelloProjectRegistration class>>primeRegistryFromImage. implementation
include latest test versions, too
checkpoint Issue #43: adding MetacelloDetermineCurrentVersionForLoadScriptTest tests

duplicated MetacelloDetermineCurrentVersionForLoadTest tests using `Metacello classic`,
now started on duplicating results using `Metacello new` and `onDowngrade:`, etc....

However, discovered that we end up with a fetching loader doing the work ... the
correct package is fetched, but no t loaded ... the loader apparently isn't being
passed through correctly ... not sure where the mistake is right now.
checkpoint Issue #43 - fix "fetching loader problem"

it turns out that the "fetching loader problem" was really a problem
with the loadDirective not being carried forward across the
mergeScriptLoads: call...
checkpoint Issue #43: update tests

test004 in progress
checkpoint Issue #43: className based registration only

prior to this commit, the registry was maintained with a projectName
index and className index.

The project name index is almost useless as different names can be used
in different configurations for the same configuration. the only
meaningful name is the className of the configuration.

While adding determineCurrentVersion tests I ran smack dab into an
ambiguity caused by a configuration with two names. I had been
considering the change for awhile now, so with this concrete problem in
hand, it was time to pull the trigger.

Switched registration to use a configurationRegistry and a
baselineRegistry using the className for keys. I split into two
registries to make lookup for baseline or configuration simpler ... the
baseline className key and configuration className key both reference
the same registration object.

This refactoring simplified the registration logic quite a bit and for
now I'm throwing errors under certain suspicious circumstances.

still working through test conversion....
checkpoint Issue #43: ... test conversion complete
checkpoint Issue #43 ... refine registrationsCompareEqual:

MetacelloDetermineCurrentVersionForLoadScriptTest>>test004new exposed a
hasConflicts: bug that caused me to rethink the definition of
registrationsCompareEqual: and I've decided that className and
versionString and operator are the only things worth conflicting on ...
all other changes repository, pre/post doits, load list, etc. are valid
things to change and should be honored without question. Of course
versionString is the big conflict, but typically that leads to an
onUpgrade: or onDowngrade: clause being triggered.

Also cleaned up some crift that was still lying around
checkpoint Issue #43: add compareEqual: logic for projectSpecs

using the className-based registration triggered problems with some of
the tests because the system was relying on the project name for lookup
rather than the className and actually causing the "wrong things to
load".

In diagnosing those problems and others, I discovered that the lookup
code was use the overrideSpec slot, even when there was no override
(from lookup), so I had to add #compareEqual to determine whether an
override is really called for or not ...

cleaned up some test errors
proposed fix for Issue #45

`ln` $PROJECT_HOME into the $GIT_PATH instead of cloning metacello-work
master branch ... should work
fix typo for Issue #45 fix...

I typed $PROJECT_HOME correctly in the commit message but not the script
checkpoint: Merge branch 'issue_43'

issue_43 will be continued once the builderCI issues get resolved
buildCI support method