directory structure of firephp-libs, insite & wildfire should be changed

[jerfowler]

The directory structure should be changed so that when you clone the repo it will have a complete copy of the firephp library in the same structure as the downloaded zip. The external libraries wildfire and insite should be added as submodules.

[cadorn]

I have documented the archive structure and contribution process here: http://reference.developercompanion.com/#/Tools/FirePHPCompanion/OpenSource/

I really don't like working with submodules and they do not support partial dependency checkouts so including them in the same directory structure as the archive would not be possible. I have opted to use include path precedence to layer a source checkout over the archive as documented in the link above.

To make things easier we could provide a script that can checkout all the repositories and provide an alternative FirePHP/Init.php file that will setup the include path properly.

Would that be acceptable? If not, why not?

[jerfowler]

I really don't like working with submodules

Why is that? Submodules is one of the reasons that makes git awesome! When developing in a team and working with git, you'll be checking out branches, pulling in code, merging changes, switching branches back and forth to test new code. You don't want to be running a script every time your testing new features to setup the directory structure. Its better to setup the structure once, and make changes to each part as you go.

Plus when there is an update to the library you just:..

git pull
git submodule update

...and your done! Some thoughts on submodule structure:

• wildfire (main project, sample programs and tests)
  • wildfire-php (php library submodule)
  • wildfire-js (js library submodule)
• insite (main project, sample progams and tests)
  • insite-php (php library submodule)
  • insite-js (js library submodule)
• firephp (main project, sample progams and tests)
  • firephp-lib (submodule of just the libraries)
  • wildfire-php (link to the php submodule)
  • insite-php (link to the php submodule)

[cadorn]

Well, the problem I have with submodules is that I have to update the reference every time I make a change in the library which is not practical in my current workflow. I find that too tedious.

You don't have to run a script for every update. You can checkout the various projects and setup your include path once. You can then pull updates and make changes to each project as you desire and your code will automatically be loaded. It is just a matter of putting the git source higher up on your include path than the archive.

Do you know what I mean?

[jerfowler]

Here is a great article on A successful Git branching model, great read: http://nvie.com/posts/a-successful-git-branching-model

[cadorn]

I am aware of that article. I am working on a tool within companion that will do all this for you (interact with git) via a nice UI. I am not prepared to maintain this via manual git commands as the current approach is working well for me. What does that have to do with submodules?

What is the specific problem with using the include path approach?

[cadorn]

There is now a repository that contains the entire FirePHP 1.0 library. See: https://github.com/firephp/firephp