On Fri, 3 May 2002, Henrik Gedenryd wrote:

...

Is it worth setting up a more sophsticated mapping from old categories to new modules so we can more painlessly file in old stuff? Any hints on how to do this? :)

One problem: the old categories at which point?

Well, some of the info is there, typically, yes? (Timestamps?)

I'd be happy if I had a chance to choose, sort like with ObsoleteClasses. But perhaps I'm misunderstanding the problem. I didn't see the advantage of my going through and replacing things by hand. If I'm going to have to replace things, a little help would be just fine by me :)

They've been changed many times. How does the fileIn know what version of the categories were used?

Again, I can accept the need for programmer advice and aide. So it reduces, perhaps, to a UI problem.

Perhaps one could associate a file with the .cs giving a mapping?

I've made a cs (attached) that ignores the categories for the base image classes. That makes it unnecessary to edit the categories, but it also swallows any old-style category string without checking for consistency with the new scheme. This however causes any category string to be accepted and so makes strange bugs pass by without alarm, just ask Ted & Scott ;-) It is bound to cause bad problems.

That, surely I don't want. I just don't want to have to 1) munge change sets with a text editor, 2) maintain two changesets in parallel, but 3) I want to develop, deploy, and port from premodule images. I wouldn't mind explicitly setting up the mapping *once*, for example. (To be changed only by my deliberate act, e.g..)

So that's why I prefer it not to be in the standard image. Of course improvements that solve the problems (how?) are welcome.

I'm just starting to work with them. My last shot founder on the I just couldn't do anything problem. Hope to move on :)

Cheers, Bijan Parsia.