migrate from comment_cck

BTW, the above goes for unstable3

needs a little design to be generic, and a little thought to know how many might be brought from comment_cck
until now, I identified:
- userreference
- nodereference
- content_taxonomy

¿is there something else?

the most important thing to keep in mind is preserve comment_cck table
never "uninstall" it
when the time comes "disable" it, but keep the table {comment_cck_revisions}
I would recommend backing up both: {comment_cck_revisions} & {comment_driven_log}, since my first migration attempts failed because of silly bugs and thanks to table's backups I was able to start fresh again once bugs got fixed

nevertheless, this will have to wait a little longer, since it is a feature request, and bugs will get more priority

as I previously said, I can guarantee:
- userreference
- nodereference
- content_taxonomy
- other (if properly reported, haven't heard yet)

this is not abandoned, I started a UI to diagnose the migration before proceeding
afterwards, a lot of code needs to be migrated to generic cases and tested (for which I'm counting with users' feedback in trial environments)

luckily, there was a wise decision from comment_cck to preserve revision change history (opposed to comment_alter_taxonomy), therefore, migration won't be affected by any bug comment_cck might have as long as revision numbers are accurate (I think they always are, haven't heard of any bug regarding this)
thus, comment_driven builds its history by comparing revisions, and also follows the same wise decision of keeping revision change history.

@#5 it is planned (as the project description states), please start an issue for it

migrating dates... I forgot them

@#5 you're welcome to try it #734446: support date fields

I'm gonna be working on this a few days, lets see how far I get

Migration should be pretty seamless

indeed, migration is based on {comment_cck_revisions} table

I was unable to test the migration

I haven't committed any code related to it

or should I just wait for the next dev. release?

Not sure when it will be committed, right in this moment I'm making huge refactors to make the API more flexible and in passing by I'm testing the core of migration
soon you will be able to play with migration sub-mods (named "inspector" and "import"), which will let you test whether all fields you have are supported or not
also, you will be able to migrate to comment_driven without having them all supported, since the "inspect" sub-mod will allow to re-import changes when new fields get supported or even correcting damage that occasional bugs might cause

or even correcting damage that occasional bugs might cause

lets make it clear, by "damage" I'm referring to the {comment_driven_log} table, which caches data that eventually might stop being compatible with newer versions (or be affected by an occasional bug)
and with inspect/import that data can be regenerated from revision vids as many times as desired

you can start trying the "inspect" tool, which will report how accurate migration path is being planed

install "inspect" sub-module (which requires the main API module, of course)
(property providers sub-mods are not required though)

look for some comments handled by comment_cck (with and without introduced difference, i.e. diff summary table)
keep their cids at hand
(also phpMyAdmin might be helpful to find cids into {comment_cck_revisions} table,
but won't have a way to know for sure if those cids introduced changes and which ones)

navigate to admin/build/comment_driven/inspect
and submit a list of cids (separated either by commas or spaces)

check whether the rendered "live comparison" matched the diff summary tables provided by comment_cck,
most of all, when there are missing fields/values in live comparison

if errors/warnings arise, check recent logs for details (or dumped data)

nop
never received the proper feedback
(actually, never got any feedback at all)

At least the feedback you were asking for in #14 is "comparison looks
correct, no errors or any other kind of problems arised".

in no way that could be a proper feedback,
I'm asking for exhaustive tests,
throughout possible config combinations

I know most of the times comparison looks correct
otherwise this module would be unusable

I believe
there should be pretty easy procedure to convert the comment cids and
node revisions into Comment Driven format.

half true,
there are kind of fields fully supported,
others have pending bugs,
and there have to be a lot without support yet

those supported are straightforward,
the ones with pending bugs are waiting for more feedback and/or free time,
the unsupported ones haven't being reviewed, so I can't say..

If you can provide such procedure

it was a long time ago the last time I dealt with it,
that code is dusty already
and judging the quality of the feedback received so far... I rather focus on other things

I am willing to give it a try on a test site mirroring the
production system with at least 1000+ nodes worth of testing material.

your willingness is appreciated,
but it is not a matter of large volumes of the same kind of data,
it is more about the gazillion possible ways to configure a field (or a set of modules)
which haven't been tested

and I know problems can arise,
checkout the issue queues (http://drupal.org/project/issues/driven & http://drupal.org/project/issues/comment_driven)
and you'll see some tickets I haven't decided how to address

that's why the migration was halted in the first place,
because I don't wanna drag people into false hopes,
neither wanna spend time attending complains about some specific configs
and be left without the proper feedback

the proposal on this ticket was:
- test your cases thoroughly
- report back with details (internals / dumps)
- and then the predominant cases might get some migration drafts
- after drafts being reviewed... etc

but we never got there..
(and we won't get there with a comment or two)

At least the feedback you were asking for in #14 is "comparison looks correct, no errors or any other kind of problems arised".

and BTW,
#14 states clearly: use the inspect tool

that piece of code was made just for those asking for migration paths, but it hasn't been used
(just one or two developers used it to report their issues)

do you want to keep wasting my time?