Duplicate functionality

We've checked Features and Deploy module. Of course, they're similar modules (export and import process) but they weren't exactly what we needed (or so fast as we'd like).

• We want to do all exports/imports as quick as possible. We don't want to create one or more submodules (like Features) to achieve it.
• For our projects, we use to have any View and CCK element into a separated file. It's useful because using SVN, let us to save all changes for every element (Views, CCK, ..) and track version changes. In Features module, all the exports are saved in same file (not separated). One file for Views, one for CCK, ...
• We'd like to choose the path where every exported file is saved.

In my opinion, Features module is perfect to combine different Drupal elements in just one module. As well, control dependencies is very great. However, we only want to have these elements updated without having to package them.

I'm going to commit first module release, so you'll be able to test it. Besides, I'll create some basic documentation and point out the difference with similar modules like Features or Deploy module.

Fabián Ruiz
STRABINARIUS

"drush features-update" is VERY fast, "drush features-update-all" is faster again ;-)

"# We want to do all exports/imports as quick as possible. We don't want to create one or more submodules (like Features) to achieve it."
You could create only one module to attach them (but it is not a pretty way to use features :-/ ). But i think It's just a point where's features is obscur : features is just a module with views and cck (and so on) attached.
So i'm working in the other direction : some of my modules become features; i don't CREATE a module just for a feature, i'm just developping as usual and use some of my modules are features. (we can add as much code as we want in a features module)

The main reason we don't use Features (and use Briefcase) is because we want every exported item into a separated file, without having to create or manage modules.

Why? Because it let us track changes for every exported item using a SVN repository.

Of course, with Features you can use SVN and track changes of your Features module file. Even you can organize your export items with one module for Views and other else for CCK and so on... It works and it can be enough for some projects. But when you have a big project (for example, 15 CCK's and 20 Views) and you just want to compare one of yours View's changes (SVN) or revert a CCK to previous version, it becomes thorny because you've a file with hundred of code lines and different functions to compare.

Fabián

Ok i see your point, even if i don't feel the need for versionning every single cck fields and so on, in the same environment. And i feel that features bring me more advantages, cause actually he supports more exportables (imagecache, cck, views, panels, context, permissions, menu and a few more).

When you importe views with this module, do you make them live "in code" with a hook default_views or do you recreate it in the database ?

Features allow to make exportables (as far as possible, cause cck can't live in code for now) live in code wich is a strong point for my choice, for the moment.( it allows versionning + make staging easier)

Ii will try your module with pleasure, just wondering if it make sense to me to use it in my workflow, compared to features :-)

perhaps it could be possible to make briefcase work as a module which enhances features, providing the split element methodology, so that features exports one element per file.

or that is a long shot?