I started off symlinking individual extensions (without modman), and that got a bit complicated, then moved towards a single repository for the entire project. That’s been nice, and it’s always comforting knowing you can rollback the entire project in one `git checkout` if you need to. But I’m beginning to work on an extension that I need to deploy to multiple Magento instances, so I think it’s time to go back to modman’ing it up.

Thanks!

This is a good line to delete all symlinks in a directory, which works well if you need to start from scratch on your modman setup, assuming of course that you haven’t put any other symlinks in the magento installation

find . -maxdepth 1 -type l -exec rm -f {} \;

Thanks for the reply!

After a few days of research, I’ve also come to the conclusion that there isn’t an easy/elegant way to do this. What I think I’ll have to end up doing is developing the custom theme / code changes off the live server to integrate when stable as there aren’t too many database changes involved and those that are can easily once the 2nd site is live.

Once I have a second, stable storefront up I can populate it with data (products, categories, etc) on the live site under a temporary test domain name, which will ensure that the data for both sites is reflected in the one live DB.

Again, not perfect, but the least complicated solution I’ve seen…..

Thanks for the feedback. That’s a tricky situation.

Normally with new store’s I’d set up CMS blocks/pages via a module sql resource but in your case there’d be a painfully large amount of configuration required.

I don’t have a really good solution to your problem, I cheated a bit when I added a wholesale substore to an existing live retail store. I actually configured it as a substore on the live site, but developed the template and code changes (installing Vinai’s Customer activation module for example) through modman as normal.

Maybe you could do a dump from core_config for the specific store, but there’s lots of other settings to worry about too (i.e tax).

If you come up with a solution that works well please let us know.

However, I’m not sure how to proceed given that one database supports both a live site and a development site. As we develop the new Magento site offline, the live site’s DB information is being changed. Conversely, the information added on the development platform isn’t reflected in the live site. The problem is that two databases are constantly changing, and those changes need to be merged at launch of the second site.

I’ve considered developing the new Magento site on the live server under a development domain (in order to share a DB with the live site), as well as trying to merge both versions of the database when we’re ready to go live with the second Magento domain. However, both seem like poor and/or complex solutions. Based on your experience, could you offer any recommendations for this situation?

You do address that and are correct in that you can’t re-tag in Subversion – but this is a problem which Git overcomes. You can have a designated stable branch (typically called ‘master’), and you can tag within a branch if you so wish (so you might have stable-1.0 and stable 2.0 for different sites). Or jsut use the HEAD revision. Any unstable developments can be done in other branches – thus not polluting the stable branch.

You would then set up a Git repo for each project and use submodules to pull in the Magento core and the various extensions you need, referencing the correct branches/tags.

Basically, I only want to check-in code for my theme and customisations to my own repo. Everything else (the core folders) I would add as extensions. As you say, I shouldn’t be editing those anyway.