I am interpreting your concern in two different ways, so I'll clarify my assumption and answer both:
------------------ Interpretation (1): You want to develop a new plugin, and find it hard to find the right files to track inside a cli created workspace. If you want to "develop some feature or plugin", I suggest you do not first create a project in the cli and try to write your plugin directly inside there manually. Instead, create a new plugin using the plugin dev guide[1] and spec[2], creating it in a separate folder/repo. It seems we don't have a great "overview" page about how to create a plugin directory structure. I'll see about adding that, but for now, just consult another plugin structure, such as cordova-plugin-device[3]. Once you've started writing your plugin, and have at least the bare bones structure, create a cli project to consume it: cordova create App ... && cd App cordova platform add ... cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN cordova prepare ... Now, every time you make changes to *the original* plugin, you'll need to re-add it from source: cordova plugin add PATH_TO_YOUR_LOCAL_PLUGIN // Doing this should overwrite the old version cordova prepare ... Then, Iterate! (We may simplify that step with a "plugin upgrade" command one day) Note: If you make mistakes in your plugin.xml specifications, the install may fail and you may end up with a slightly awkward workspace, and will need to manually delete some files, or just re-create a new workspace for testing. ------------------ Interpretation (2): You want to version an entire workspace you've created with cordova-cli. You can do this, but, cli created workspaces have a bunch of "build artifacts" and it serves little purpose to actually track changes to them (in my opinion). The pieces that are actually worth tracking are the original sources: platforms, plugins, and your app(s). If you would like to manually track versions of platforms or the core plugins, you are free to clone the git repos manually, and use cordova-cli to add them from local paths. This way, you can also make downstream changes inside feature branches etc. If you do not actually need to make changes to platforms/plugins, it is easier to let CLI automatically fetch the latest stable versions for you, or fetch specific version you request for you, and trust that we will serve good working versions. You can always revert to older versions if issues come up. Again, you can of course add the whole workspace into a repo and share that across a team, but much of those files are created as a result of file munging and will change in odd ways over time. ------------------ [1]: http://cordova.apache.org/docs/en/3.0.0/guide_hybrid_plugins_index.md.html#Plugin%20Development%20Guide [2]: http://cordova.apache.org/docs/en/3.0.0/plugin_ref_spec.md.html#Plugin%20Specification [3]: https://github.com/apache/cordova-plugin-device -Michal On Fri, Aug 30, 2013 at 5:51 AM, lmnbeyond <lmnbey...@gmail.com> wrote: > Hi all, > > Cordova was separated into tens of individual repos ever since 3.0 > and we're benefit from this change and can quickly build/test apps. > > For now, if I want to develop some feature or plugin, I can first > create a project by cli, then did some changes, but meanwhile it's > difficult to track which files got changed/added/removed, since all source > was not under source control. And it's also error prone to manually do the > tracking. The structure of cordova-x repos is different from the structure > in a development project. > > It was easier if there was an all-in-one project, I mean all > native sources in a single project, before 3.0. > > > Best Regards! > > > >
