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.