Спасибо за развернутый ответ. Для сборки prodcton-версии проекта я смотрю в сторону PHP Composer, сборку девелоперской версии без монтирования в проект исходников всех зависимых модулей, участвующих в разработке, я пока не представляю. Допустим, я могу отказаться от субмодулей gt'а, Но от монтирования в девелоперскую версию модулей, находящихся в различных репоизиториях (как того ожидает тот же composer) я уж точно не смогу отказаться. Это сильно затормозит (да что у ж там — остановит) проекты в которых я участвую — разработка e-commerce приложений на базе Magento. Я не представляю, каким образом эмулировать Magento для разработки Magento-модуля в «чистой среде», а особенно, когда у меня есть код, общий для всех наших проектов, и специализация кода под конкретный проект. А это минимум два модуля, которые должны девелопиться параллельно. А потом до общего модуля «докручивается» функционал специализированных модулей и в других проектах.
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
А у нас архитектура такая — есть модуль, в котором лежит функционал для всех наших проектов (задает поведение), есть модуль в котором идет реализация поведения для связанной группы проектов, есть модуль специализирующий поведение для конкретного проекта. И если я реализую базовую функцию, то я могу вносить изменения одновременно во все три модуля.
Если с сабмодулями не хорошо, то что в них плохого? По мне — так это просто нативный способ компоновать единый проект из разных репозиториев. То, что я в SVN делал при помощи sh/cmd-скриптов теперь могу делать нативно на уровне git'а. Насколько хорошо — другой вопрос. Но в чем зло? Или вы рекомендуете использовать старые-добрые shell-скрипты для монтирования проекта?
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
Чем плохи сабмодули? И как переходить на «версионированные бинарные зависимости» (и что то есть для PHP?), если для решения какого-либо таска мне нужно править исходный код сразу двух-трех модулей в рабочем окружении? Ну, допустим, я целевую систему соберу из «бинарников», а разрабатывать как?
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
У нас есть core-модули, которые участвуют в нескольких наших проектах, поэтому все изменения мы протаскиваем через SVN. Есть система скриптов, которая позволяет монтировать из SVN наши модули в структуру Magento-сервера, а также коммитить все изменения во всех модулях и обновлять их. Монтирование происходит на уровне каталогов, не файлов — SVN этого не позволяет.
При рассмотрении альтернативных средств развертывания пришли к modeman и Magento Composer. modeman вообще не работает с windows, а Magento Composer требует донастройки прав пользователя для своей работы. Поэтому вполне логично появилась мысль мигрировать на linux. Лишней машины у меня нет, да и переключаться между двумя наборами клавиатур/мышек не комфортно, а виртуальных linux-серверов (именно серверов, а не десктопных рабочих станций) — штук 5. Поэтому и родилась идея запустить phpStorm на удаленном сервере с доступом с wind'ы. Чтобы можно было в linux-среде изучить возможности развертывания через Magento Composer (hardlinks!!!) без разрушения основной рабочей среды (Windows) и не создавать при этом новых инсталляций.
Этот пост родился в силу того, что я только в одном месте нашел указание на последовательность действий при запуске x-приложений на linux-машине с доступом к ним с windows-машин через Xming. Если бы я сразу вышел вот на эту страницу, я бы и написал этот пост, но так как я потратил довольно много времени на «плутание в трех соснах», да и чтобы закрепить результат, я написал пост в Хабр (хотя мог и в корпоративную вики).
Кстати, так можно и не только PhpStorm запускать, но и другие x-приложения с удаленной машины. И я использовал PhpStorm как локально (из офиса), так и удаленно (из дома) — вполне рабочее решение. Особого дискомфорта я не испытал, правда у нас интернет довольно хороший. Посмотрю еще VirtualBox, если получится разобраться с ним и развернуть рабочую среду за пару-тройку часов.
Вот в том-то и проблема, что файлы лежат на Windows-машине, а windows не поддерживает hardlinks в полной мере. Система развертывания модулей для Magento modman, например, под windows не работает. Поэтому одним из ограничений является, что файлы должны лежать на linux-машине.
Я разрабатываю под Magento — там очень много файлов в проекте. Не всякая IDE потянет. Например, Zend Studio в свое время не мог прочитать полностью проект со сторонними модулями из-за кольцевого наследования в каких-то классах. Я часто использую поиск по всем файлам проекта и опасаюсь, что sftp-шная папка будет меня сильно тормозить. Хотелось запускать IDE локально.
PhpStorm — это мой IDE (или мое?). Использую я его для разработки модулей к Magento. Сейчас решаю задачу, как разворачивать и поддерживать Magento-проект с моими модулями, лежащими в Git-репозитории. Смотрел в сторону Magento Composer, но он работает на hardlinks, которые есть в *nix-системах, но не очень есть в win. Поэтому нужно было принципиальное решение. Вообще-то целью статьи было описание последовательности действий при работе с Xming — несмотря на простоту подключения мне было непонятна последовательность действий и как этого зверя использовать. PhpStorm просто как пример :)
В принципе, довольно неплохо, работать можно. Сильно не использовал, но особых тормозов не заметил. Для девелопмента подходит — там думать нужно больше чем писАть.
ОК, вынес важную для себя мысль — сабмодули у народа не в подчете. Буду ступать осторожнее :)
В тексте по ссылке говорится, что PhpStorm не поддерживает команд Git'а по работе с сабмодулями в одном проекте, но вот опыт MetalGuardian говорит о том, что PhpStorm и без этого неплохо справляется.
Ну и если сабмодули реальное зло, то "storm и без сабмодулей адекватно работает с несколькими репозиториями в одном проекте" (с) :)
При рассмотрении альтернативных средств развертывания пришли к modeman и Magento Composer. modeman вообще не работает с windows, а Magento Composer требует донастройки прав пользователя для своей работы. Поэтому вполне логично появилась мысль мигрировать на linux. Лишней машины у меня нет, да и переключаться между двумя наборами клавиатур/мышек не комфортно, а виртуальных linux-серверов (именно серверов, а не десктопных рабочих станций) — штук 5. Поэтому и родилась идея запустить phpStorm на удаленном сервере с доступом с wind'ы. Чтобы можно было в linux-среде изучить возможности развертывания через Magento Composer (hardlinks!!!) без разрушения основной рабочей среды (Windows) и не создавать при этом новых инсталляций.
Этот пост родился в силу того, что я только в одном месте нашел указание на последовательность действий при запуске x-приложений на linux-машине с доступом к ним с windows-машин через Xming. Если бы я сразу вышел вот на эту страницу, я бы и написал этот пост, но так как я потратил довольно много времени на «плутание в трех соснах», да и чтобы закрепить результат, я написал пост в Хабр (хотя мог и в корпоративную вики).
Кстати, так можно и не только PhpStorm запускать, но и другие x-приложения с удаленной машины. И я использовал PhpStorm как локально (из офиса), так и удаленно (из дома) — вполне рабочее решение. Особого дискомфорта я не испытал, правда у нас интернет довольно хороший. Посмотрю еще VirtualBox, если получится разобраться с ним и развернуть рабочую среду за пару-тройку часов.