How about doing it as a post load script like this (tested on my local package-cache)...

oldPackageName := 'ShoutTests'.
newPackageName := 'Shout-Tests'.
repository := MCRepository allSubInstances detect: [ :repo | repo location =��
'/Users/ben/Library/Application Support/Pharo/package-cache' ].
" 'http://smalltalkhub.com/mc/Pharo/Pharo40/main' ]."
oldPackage := RPackageOrganizer default packageNamed: oldPackageName.
newPackage := oldPackage renameTo: newPackageName.
mcWorkingCopy := newPackage mcPackage workingCopy.
uniqueNewVersion := (mcWorkingCopy uniqueVersionNameIn: repository) trimBoth.
newVersion := mcWorkingCopy��
newVersionWithName: uniqueNewVersion��
message: 'Issue 14439 - ShoutTests should be Shout-Tests'
in: repository.
newVersion ifNotNil: [
Cursor wait showWhile: [
[ repository storeVersion: newVersion.
] ensure: [ (MCVersionInspector new version: newVersion) show ]
]
].

For reference, I munged that together from tracing NautliusMonticello>>commit:in:��

cheers -ben

On Sat, Jan 24, 2015 at 1:33 AM, Ben Coman <btc@openinworld.com> wrote:


On Fri, Jan 23, 2015 at 8:00 PM, Torsten Bergmann <astares@gmx.de> wrote:
Hi Marcus, Ben and others,

how can we proceed on META issue https://pharo.fogbugz.com/f/cases/14447?

Anyone with deeper knowdlege of Monticello and the integration process
able to help here? It's a merging issue although nothing to merge.

Thx
T.


Actually, I discovered that the problem only occurs when you wrap the package in a slice.�� Given that these will be isolated single package updates, without needing to synchronise with other packages, would it be possible & pragmatic to load the packages directly without a slice, to get the issues out of the way.�� Or maybe a script that does the rename and then pushes the dirty packages to the repository?

Now do we need to be concerned with the oldnamed package being an ancestor of the renamed ?

cheers -ben