On Nov 9, 2011, at 8:53 AM, Lee Hambley wrote: > 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. ---- I get the impression that 'namespace :deploy' has a magic to itself that will perform the subversion checkout magic that I can't seem to make happen in any other namespace.
Craig -- * 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