Add support for migrating node revisions

As the edit in the original topic indicates, Migrate itself has no support for node revisions at this time, there is an open feature request for this support: #1298724: Maintaining node revisions?. Revision support isn't on the immediate roadmap for Migrate, but patches from the community are certain welcome - once the basic support is in Migrate, adding it to migrate_d2d shouldn't be difficult.

New info

#1298724: Maintaining node revisions? has been committed to Migrate, so it is now possible to add this support to migrate_d2d. I'm not sure I'll have time to tackle this for the upcoming 2.1 release, but if someone offers a patch that would help expedite it.

How should he do this?

I've started hacking on this. Hopefully, I'll have a patch soon!

Ok, here's my first attempt at this patch! There's lots that needs to still be done, but it appears to work in some limited testing.

There's a couple things that worry me, though...

Namely, because it depends on a previous node migration, you'll basically be putting the revisions in order ON TOP of a node that has already been migrated with the latest revision.

In the blog post that spawned all of this:

http://darrenmothersele.com/blog/2012/07/16/migrating-node-revisions-dru...

... the author is making the node migration pull in the first revision (rather than the latest one) and then skips the first revision when pulling in the revisions. This would totally work, but it creates two problems:

1. The boilerplate for only pulling in the first revision is non-trivial and requiring users to do this themselves any time they want to import revisions would be ... lame. But there isn't a really obvious base class to put this code so that it was easier to do.
2. You end up duplicating your mappings in the node migration and revision migration, since you're essentially migrating the same thing. The best DX (developer experience) would be to only write one migration that got everything...

Anyway, I'll keep thinking about this and post a comment if I have have any updates!

I have no new good ideas. :-/ I think I'm going to run with this patch for now, and come back to this later if I come up with anything better.

:(

One more quick note: I'm working on this for a publicly available project, Open Atrium Migrate.

So, you can see some classes and configuration I have using this here:

http://cgit.drupalcode.org/oa_migrate/tree/includes/node.inc

One of the more useful bits is probably where it alters the query to only get the first node revision, when migrate the nodes:

http://cgit.drupalcode.org/oa_migrate/tree/includes/node.inc?id=ec565e0b...

And getting all but the first revision when migrating the revisions:

http://cgit.drupalcode.org/oa_migrate/tree/includes/node.inc?id=ec565e0b...
http://cgit.drupalcode.org/oa_migrate/tree/includes/node.inc?id=ec565e0b...

I hope that's helpful to anyone who comes along later!

@Ryan Weal: If you know a way to make this work with only a revision migration, please let me know! I don't know how to do that because we need to generate two "maps" in the end (one for nid's, the other for vid's), and Migrate makes the assumption that each Migration only has a single map. But if there's a workaround, that would be awesome. :-)

Necessary to migrate some of the simple node revisions?

This issue could do with a summary update outlining what is the situation and challenge now that the Migrate module has revisions support as of April.

@Ryan Weal; can you confirm if there is a possible scenario now where it might be sufficient to only migrate revisions and not the NIDs? I am struggling with understanding what exactly is recommended here now.

For example, @Ryan Weal wrote in #9:

"Indeed, it is not necessary to migrate nodes if you've got a revision migration for that content type. If you're running both it may be useful to skip the first revision, or alternatively just not run the node migraiton when you have a revision migration available."

Is just a revision migration enough?

What does it require to be done afterwards?

A use case/scenario would be nice.

For example:

I have a completely new web site on D7, with new, partially different content and focus, but have an old site with lots of useful references that I would like to import as unpublished revisions with their internal relations intact, so that I can one by one pick which one I want to edit, publish, make a new revision from so that after I have published it, it would have "inherited" all the previous revisions in its revision history, available for the users with sufficient permissions to view revisions.

Is that possible now?

More work is needed here - besides the discussion above, there should be D5 and D7 versions of the migration, as well as support in the UI wizard (although the latter may best be addressed in a separate issue dependent on this one - just make this one about the API).

Any idea?
Related link: http://drupal.stackexchange.com/questions/160027/drupal-node-migration-m...

The question (so people don't have to follow the link) is how to migrate D5 node revisions? And the answer is for someone who is sufficiently motivated, to finish the work in this issue (including extending it to D5).

@mikeryan: I do not know so much about Migrate and Migrate D2D. I could not find a example the MigrateDestinationNodeRevision. I could help the core profile field migrations, but unfortunately this I can not. :(

(Sorry, my english is bad)

@nevergone: Check out the oa_migrate project for an example:

https://www.drupal.org/project/oa_migrate

It uses the patch from this issue.

@dsnopek: Thanks, it's working! :)
dsnopek++

Hi Folks,

Sent this as a message to dsnopek, but I'm guessing he's swamped doing lots of other fabulous work, so I'm hopeful others on this thread are able and willing to help a patch-newb.

I've placed the patch in the root migrate_d2d folder (hope that's correct, although thought it might need to be in D6 folder based on limited understanding of patch interpretation).

Any insights into what I'm doing wrong? Here's my input/output from my Mac Terminal app:

patching file node_revision.inc
patching file migrate_d2d.info
Hunk #1 succeeded at 15 (offset 1 line).
Hunk #2 succeeded at 39 (offset 3 lines).
The next patch would create the file node_revision.inc,
which already exists! Assume -R? [n] y
patching file node_revision.inc
Hunk #1 FAILED at 1.
File node_revision.inc is not empty after patch, as expected
1 out of 1 hunk FAILED -- saving rejects to file node_revision.inc.rej

Pls. do not change the category.
Try reading https://www.drupal.org/patch to learn about how to work with patches.