Follow me as I journey down a shaky path. 

Goal: I am moving some cck fields off of a Quote Node down into the experimental/abandoned/phantom project content_multigroup* whilst keeping the values from the database.  It is to be done with a combo of Feature revert and hook_update_n.

Plan: Leveraging the fact that reverting to Feature code with fields missing (removed) from Drupal/database does not in fact drop the db columns from the content_type_<type> table structure, I should be able to:

Miss the old Drupal 6 recipe of:

cck node type + nodereference + nodereference_url + views_attach of Drupal 6 and days gone by?  Fear not-- you can still do it in Drupal 7 in much the same way, just with different names:

So here I am, pushing against deadlines, pushing to staging, preparing to push this ginormous update to a production, and I notice that my roles are no longer being honored at staging in this View!  *yikes*  I'm going to propose using hook_perm to define some appropriate role permissions instead of "multiple roles" under Views Access.  Here's to innovation, let me know what you think.

Back story:

Feature won't revert?  Or not all the way?  .. Here are some scattered thoughts in the wind about what I just solidified in my mind:

• drush fd featurename
  doesn't actually go and refresh Features' understanding of db and file contents: it seems to work off of what it remembered from when you last ran drush features in order to get a features diff.
• drush features
  does refresh and reconcile differences of db and file

Trying to do:

I can't believe it's taken this long to add node_export to my Drupal development workflow-- so simple, check it out!

At local dev: