Then you have two independent projects, not two stages. I recommend using git submodules, still - and tracking your i18n separately, and when you need to "deploy" your translations, make a one-liner task go to the app, and do a `git submodule update`. Then Git (a content tracker) will track when your translations were last deployed (or rather, what version was last deployed, which I'd wager is just as important.)
And your developers won't have to care about checking out and symlinking, and keeping up to date two trees, and your deployments will always be a one-shot, with an option to deploy translations when they become available without requiring an extensive re-deploy of the whole I18n tree, and re-symlinking into the project root. I guess my point is "use your tools" - symlinking/etc on the filesystem and deploying two separate stacks, and symlinking codebases with interdependencies is going to be horribly unreliable, and violates the principle of least surprise (submodules were designed to solve this problem (dependent projects with alternate release cycles)) so why not leverage them to your advantage? Sounds like you're resisting a bit, because you are already invested in this route, which I fear may be a mistake for you. - Lee -- * You received this message because you are subscribed to the Google Groups "Capistrano" group. * To post to this group, send email to capistrano@googlegroups.com * To unsubscribe from this group, send email to capistrano+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/capistrano?hl=en
