Symphony.

Sometimes i just want to create a project, as fast as possible, into my own repository. I want to be able to quickly add extensions, be able to update them when they change and still have it all in one repository that i can clone, push to a server, backup etc etc.

Submodules can be a pain so i started to create a builder script:

https://gist.github.com/1442200

Symphony project builder

These scripts allow you to use Symphony and Symphony extensions as subtrees to your own project.

What is this:

There are 2 files:

• SymBuilder.sh
• AddExtension.sh

Symbuilder creates a new repository (your project) and adds Symphony-cms as a subtree and merges it into a web root (like public_html)

From now on the symphony repository is a real part of your repository. (not a submodule). You can't push back to the original repo but you can pull from it! So when the Symphony repository is updates, you can pull those changes into your own repo.

Symbuilder copies AddExtension.sh into your project folder. This script allows you to add extensions to your project in the same way we just added Symphony.

How does it work:

This is what SymBuilder.sh does:

./SymBuilder.sh [project name] [webroot]

1. This creates the folder [project name] and runs git init in it. This is your project repository.
2. It adds some files (.gitignore, .symbuilder, AddExtensions.sh) and commits those.
3. Then it Adds a remote called symphony-2 from git://github.com/symphonycms/symphony-2.git
4. Now it merges the symphony-2 / master branch using the "ours" strategy without committing(!)
5. Now we read the symphony-2 / master into [webroot] and update the files here.
6. Now we commit this merge to our project repository

The remote name, url and branch are configurable in the script. Default is:

SYM_REMOTE_NAME="symphony-2"
SYM_REMOTE_BRANCH="master"
SYM_GIT_URL="git://github.com/symphonycms/symphony-2.git"

This is what AddExtension.sh does:

./AddExtension.sh [extension name] [git url] [branch]

1. It Adds a remote called [extension name] from [git url]
2. Now it merges the [extension name]/[branch] using the "ours" strategy without committing(!)
3. Now we read the [extension name]/[branch] into [webroot]/extensions/[extension name] and update the files here.
4. Now we commit this merge to our project repository

This script is based on this Github Help article

Great stuff. I've just starting thinking/building something for myself along these lines.

However, I was thinking of just the following:

• Create new Project Git repo (mkdir project && git init)
• Add a new 'symphony' remote for the official Symphony-2 repo (to pull from)
• Add individual Extensions as submodules to /extensions/extension
• (Optionally setup another remote as master to push online to e.g. Codebase)

This simply uses a Remote for the Symphony Repo: easier pulling for updates and adds Extensions as Submodules: easier updating.

It seems similar to your setup but I'd love to hear your thoughts on why you chose the other (to me more obscure) options.

• Why do you think submodules (for extensions) are a pain?
• How do these git subtrees work?
• What is the "ours" strategy?

Thanks!

I like the fact that, using subtrees, i don't have to worry about initializing / updating submodules. Another great thing is that, when i want to deploy to ,for instance, PhpFog, i can simply add a new remote and push the entire site. When i would use submodules, their files wouldn't end up on PhpFog.... only the submodule reference.

I also wanted to have my own repo with symphony in a subfolder of that repo, this is so that i can add additional stuff to the repo that don't belong in the symphony folder. (this creates the symphony repo's submodules issue in my script)

this is a nice explanation of subtree :

Subtrees allow subprojects to be included within a subdirectory
of the main project, optionally including the subproject's
entire history.

For example, you could include the source code for a library
as a subdirectory of your application.

Subtrees are not to be confused with submodules, which are meant for
the same task. Unlike submodules, subtrees do not need any special
constructions (like .gitmodule files or gitlinks) be present in
your repository, and do not force end-users of your
repository to do anything special or to understand how subtrees
work. A subtree is just a subdirectory that can be
committed to, branched, and merged along with your project in
any way you want.

As far as i know, submodules work differently.

On a side note, you could use this to split another reop into another repo. not sure if this would work with angle files as well!

The ours strategy means that the branch i'm merging into my branch has preference when any conflict might occur… it overwrites whatever was there in the branch. there is no real need for it in this script but it makes the merge behave more like a blunt copy …

I'm just getting more into this "more advanced" git stuff so i might be doing stuff completely wrong ;-)

Thanks Simon. Subtrees sound like a good less-hassle alternative to submodules. One thing I wonder about is the fact that they get integrated as a subfolder. With Symphony, the /symphony folder is actually the web-root, so how do you deal with that? Do you simply create a main 'project' folder and add the Symphony subtree as 'www' or something?

I did run into some merging issues since e.g. the Symphony .gitignore file excludes the /workspace folder (and I obviously want it when deploying). Also I'd like to ignore the /manifest/config.php etc. When you use the "ours" strategy, will my .gitignore- and config.php files get overwritten?

Have you guys seen Builder — is this close?

I tried to get Builder running just now, going from error to error. I'l try further to get it working (MAMP, OSX).

Does builder leave you with a git repo of your own, without destroying the history of the symphony and extensions's repos?

My ideal solution would be a "ender" like solution, simply adding stuff from the command line, even when you are half way into the project.

Unfortunately the Builder isn't as flexible as your solution and, as you've seen, hasn't been updated for more than a year. I'm working on a new similar concept now, but I feel like nothing can beat an advanced shell script (given the user knows what he/she is doing).

Good work, I'll give this a try sooner or later.

@alpacaaa Yeah, that knowing what you're doing part ... just getting into the more advanced stuff here.

I have updated the script so it removes the default extension submodules and re-adds them as subtrees.

I'm also looking at ruby and/or Node.js as an alternative for shell scripting. No experience in either so it's more like a stare at the moment ;-)