Организация среды веб-разработки

[Rpsl]

а freeware аналогов ExpanDrivе нету?

p.s. Молодец. Ждем продолжения.

[i0ngunn3r]

NetDrive?

[Rpsl]

Он «Free for home use», так что не совсем подходит.

[leaf]

тоже посмотрел на это и приобрёл ExpanDrive, лицензия обошлась на десятку дороже чем у NetDrive

[i0ngunn3r]

Пардон, еще надо ftp>sftp бридж. mindterm например.
правда, и то и другое freeware только для home use.

[special]

Dokan SSHFS
Как установить тут: blog.azomazo.ru/2009/02/ssh-windows.html
…
После установки запускаем программу, и вписываем настройки сервера, к которому подключаемся, и указываем букву диска. После подтверждения в трее появится иконка программы, говорящая что диск примонтирован. Все можно по нему бегать любой программой.
…

Но опятьже на таком диск с SVN при помощи, например, TortoiseSVN работать не получается…

[haikuos]

coda?

[IvanT]

У нас похожая структура. Только диск подключается не софтом, а самой виндой как сетевой. Проекты доступны по адресу projec.username.company.com. Работает всё на FreeBSD сервере. У каждого на сетевом диске список папок с проектами. Каждая папка автоматом монтируется в поддомен.

[piumosso]

Скажите, а согласно Вашей системе юрлов, username.company.com на что указывает?
Дело в том, что username.projec.company.com позволяет при удалени младшего сегмента projec.company.com видеть версию репозитория)

[IvanT]

test.username.company.com -> /users/username/www/test/
username.company.com -> /users/username/www/ — корень рабочей директории пользователя. В ней лежат директории с проектами. Тоесть у каждого разработчика своя копия проекта. Только база данных общая. После окончания задачи на каком либо из проектов идет коммит в репозиторий, который лежит на отдельной машине. Если нужно вылить проект на продакшн, то жмется спец кнопка, которая запускает скрипты экспорта. С её же помощью можно посмотреть текущую версия на живом сервере проекта и откатить исходники при необходимости.

[svdesign]

А зачем именно workaround=rename? Я давно монтирую так директории и проблем с SVN не встречал, может быть потому что я один монтирую эту папку и никто другой не «мешает» мне? :)

[el777]

По идее никто другой и не должен — это же ваша личная папка.

[vstas]

У меня вот какой вопрос возник.
Допустим над проектом (project1) работают два программиста (pr1, pr2) и один верстальщик (m1), т.е. получается что каждый из пользователей получит свой каталог проекта, что-то такое:
/var/www/pr1.example.com/project1/
/var/www/pr2.example.com/project1/
/var/www/m1.example.com/project1/

Но существует ли в этой схеме вариант увидеть общий итог работы этих трех?
Т.е. когда их частные изменения собираются вместе.

Допустим работа верстальщика m1 добавляется к работе программиста pr1.
Может они самостоятельно, с помощью SVN, подгоняют свои проекты под этот общий итог?

Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.

[Rpsl]

ну, когда один из них сделал то, что ему было нужно, он делает comit, остальные уже могут сделать update и получить результат его работы в свою версию.

[vstas]

Каждый пользователь делает commit куда-то сюда, в зависимости от ситуации:
username.project.example.com/trunk
username.project.example.com/tags
username.project.example.com/branches

А как они будут делать update?
Ведь у них независимые по сути проекты.

Просто я видел немного другую организацию хранения проекта:
project.example.com/trunk
project.example.com/tags
project.example.com/branches/username1
project.example.com/branches/username2

Т.е. идея в том, что есть один проект и над ним работают разные люди. При этом конфигурирование доступа для конкретной реализации проекта в Apache можно также автоматизировать.

[vorob]

У них независимые копии проекта, а репозиторий один.

Посмотреть итог работы этих троих можно сделав пост-хук-коммит, который бы обновлял например: /var/www/build.example.com/project/, тогда по адресу build.project.example.com будет находиться самая последняя версия проекта.

Если в репозитории по ветке на каждого разработчика, то чтобы посмотреть результат работы нужно будет делать merge между ветками.

[vstas]

Просто именно описание того что есть некоторый магический build.example.com не было в статье. И я хотел узнать как у вас это делается.
Спасибо за ответ.

[vorob]

Где-то недавно проскакивала статья о создании хуков: adw0rd.ru/2009/subversion-hooks/

[vstas]

Спасибо за ссылку.
Мне просто не очень понравилась идея хуков.

Вот некоторый пример.
Пусть все будет как и описано в этом комменте ( habrahabr.ru/blogs/webdev/65005/#comment_1815206 )

Теперь допустим программист pr1 добавляет в проект некоторую функциональность, допустим новостную ленту. Когда дело доходит до представления ( шаблонов), то на начальном этапе программист сам этим занимается. Но в какой-то момент подключается верстальщик m1. Видимо он должен извлечь некоторые наработки программиста pr1 ( а если еще и pr2 работал на этой же функциональностью, то и как-то merge сделать) себе в рабочую копию. Хотя он конечно может извлечь все из интеграционного проекта build.

Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.

Мне пока больше нравиться идея, когда.
Есть проект. В нем есть trunk — основное направление разработки. Все пользователи извлекают для свой работы рабочую копию из trunk, кроме специальных случаев. commit они тоже туда делают.

Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).

Это не значит что нельзя автоматизировать просмотр извлеченных рабочий копий для каждого пользователя. Как вариант в домашнем каталоге пользователя есть каталог projects. Туда пользователь извлекает из SVN рабочую копию проекта и apache автоматически подхватывает его по адресу username.project.example.com

Но при этом всегда есть, актуальная что-ли, версия проекта.

Еще в вашем описании среды никак не описана БД. Многие проекты ее используют. Понятно что для каждого из пользователей необходима свою БД.

В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(

[tnz]

>Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают commit и
>в интеграционном проекте build будут последние изменения сделанные кем-либо из pr1, m1. Это усложняет совместную разработку.

Почему после коммита обоих в build появится только один? Наоборот при коммите изменения сольются. А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.
Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.

>Таким образом нет username.project.example.com/trunk, а есть project.example.com/trunk и в редких
>случаях project.example.com/branches/username (его «нужно» потом объединять с основной веткой разработки).

То, что вы называете project.example.com/branches/username есть почти то же самое, что и username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит модифицированный код, который надо сливать с основным проектом. А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в общую ветку.

[vstas]

> Почему после коммита обоих в build появится только один? Наоборот при коммите изменения сольются.
> А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.

согласен. немного стормозил. изменения сольются, но в любом случае если использовать предложенный post-хук это будет не так удобно делать (я имею в виду svn update перед коммитом в build).

> Репозитарий на всех один. Программист и верстальщик просто сделали checkout в свои личные директории.

> То, что вы называете project.example.com/branches/username есть почти то же самое, что и
> username.project.example.com/trunk. За исключением того, что в первом случае в репозитарии уже лежит
> модифицированный код, который надо сливать с основным проектом.
> А во втором случае модифицированный код лежит пока у конкретного программиста и ему нужно сделать commit в
> общую ветку.

Странно как-то у вас написано. В первом случае вы говорите про репозитарий, а во втором сравниваете с рабочей копией. Я вроде так и не говорил никогда. Насколько я понял не важно как обращаешься к проекту
pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?

Если это так, то я не понимаю фразу из статьи:
— У себя, внутри студии, мы выбрали следующую схему:

username.project.example.com/trunk
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
—

[tnz]

>pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?
Я так понимаю, что здесб лежат рабочии копии программистов. Т.е. это не свн. Возможно я ошибаюсь.

[vstas]

Ага. Я наконец понял что это не свн. Это и был главный глюк. Просто нужно было описание работы с SVN в отдельный подраздельчик вынести.

[vstas]

Разобрался.

[el777]

Под линукс очень удобно использовать automount sshfs — вот подробная статья по настройке. Это по сути «монтирование по требованию».

[Arefiev]

а в чем конкретно проблема с SVN и samba?
у нас аналогичная структура и все прекрасно работает и из консоли и через TortoiseSVN

т.е. нужда в ExpanDrivе отпадает

[vorob]

У нас не получалось закоммитить файл, который находился не в version control.

В то время как раз шло активно обсуждение в мейл-листе самбы на эту тему www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html

Сейчас может быть ситуация с выходом новых версий изменилась.

У вас какая версия svn и самбы?

[Arefiev]

svn и 1.4.х и 1.5.х, про самбу точно не знаю, но такая система в нашей конторе уже сильно больше года работает

[WarGoth]

Вы пользуетесь сразу двумя версиями SVN для одного репозитария?

[Arefiev]

:) нет конечно — разные проекты, разные dev-сервера, разные репозитории

[WarGoth]

У нас в офисе настроено так же, как описано в статье. И тоже существует проблема с рабочими копиями на самбе. Причем эта проблема проявляется у разработчиков, которые пользуются линухом. Под виндой все нормально. Проблема (предположительно) заключается в несоответствии UID и GID серверного (из-под которого открывается досутуп к шаре) и локального (который пытается примонтировать) пользователей. Поэтому одно из решений, которое у нас успешно работает — изменить локальный UID/GID, приведя в соответствии с серверными. Я же принципиально пользуюсь sshfs, хотя испытываю дискомфорт от тормознутости.

Третья альтернатива — NFS, которая намного лучше подходит линух-пользователям, чем самба.

[WarGoth]

PS. Подтверждаю, что без опции workaround=rename работать невозможно ввиду интенсивных переименований в служебных папках SVN во время операций с деревом.

[andry]

Хорошая схема, ее много лет назад обсуждали в инете и конфах, теперь думаю она с теми или иными вариациями у очень многих работает.

[ivankin]

Eclipse + Subclipse — проблем на винде, линукс и макосе в шарами самбы проблем не имеет.

[kurokikaze]

А какой IDE, если не секрет? Eclipse?

[nerezus]

Спасибо за ExpanDrivе, не знал про нее. А бесплатные аналоги есть?

[pwlnw]

Похоже, совсем не используется удаленная отладка?

[nerezus]

Просто модуль для пхп добавить.

[pwlnw]

Я не у вас спрашивал, но раз уж вы считаете это тривиальным, опишите какой модуль и как его следует настроить, чтобы множество разработчиков могло отлаживать и не блокировать работу друг-друга.

[nerezus]

А разве одновременно возможна лишь одна сессия дебага? о_О
я в phped втроенный юзаю, как вариант от zend'a отладчик или xdebug.

[pwlnw]

По-моему нет, но настройка xdebug.remote_host предполагает один постоянный хост.
Просто интересно посмотреть как админ выпутается.

[myem]

ой ли?
.htaccess:
===
php_value xdebug.remote_host %my-remote-ip%
===

Понятное дело, нужные опции для .htaccess из конфига Апача должны быть включены.

[pwlnw]

А если двое программистов работают над одним проектом (каталогом)?
Наверное через SetEnvIf можно

[myem]

Боюсь, что ОДНА физическая директория для разработки проекта несколькими программистами — это ОЧЕНЬ тесно и плохо (при активной разработке и близких задачах). Причем считаю так, основываясь и на своем, отрицательном опыте в этом плане.

[pwlnw]

Ну так и что? они все равно так работают. В один файл index.php, в который с помощью modrewrite сгоняются все запросы. Это модно.
До тех пор пока не встает вопрос об отладке.

[myem]

Приведу простейший пример: разрабатываются одинаково подключаемые одновременно модули, и для контроля «всё ли происходит как надо» оба программиста в своём коде добавляют var_dump(). После чего получаем взаимную феерию с, иногда, тяжкими последствиями.

[pwlnw]

Неважно что там у вас было на практике. Приложение УЖЕ построено наихудшим образом из кусков опенсорсных и самодельных велосипедов.
Предложите лучше красивую схему отладки и взаимодействия.

[myem]

Дык, кажется, в статье о том речь есть: каждому по самостоятельной копии приложения, которую каждый в своей директории дорабатывает, многодоменность — через тот же mod_rewrite, сведение работающих и отлаженных доработок — через всё тот же svn.

Ну и отдельно, само собой, live-версия.

[akhkharu]

Вот и у нас такая же проблема — хотим использовать такую схему, но скорее всего нельзя будет использовать отладку одновременно для нескольких клиентов. Во-первых, у нас есть клиенты Windows (PHPEd, dbg) и Linux (Netbeans, xdebug), а прикрутить два модуля одновременно вряд ли получится. Во-вторых, даже если учитывать только клиентов Netbeans, сомневаюсь, что Netbeans умеет работать с отладочным прокси-сервером.

Жаль, но без отладки никак.

[SixDays]

А может быть всё-таки попробовать Eclipse-PDT + ZendDebugger? У него точно есть возможность много хостов указывать.

[akhkharu]

Eclipse-PDT, к сожалению, напрочь отказывается создавать проект (Битрикс)

[akhkharu]

Похоже, что в случае WiFi этот способ использовать комфортно не получится: Netbeans постоянно подвисал при скроллировании дерева проекта и при прочих операциях с файлами, а у нас был всего лишь один клиент…

[vorob]

А как монтировали директорию?

[akhkharu]

Как было сказано в топике, через sshfs с настройкой workaround=rename

[vorob]

Попробуйте примонтировать с использованием компрессии или кэшированием:
...
-C equivalent to ’-o compression=yes’
...
-o cache=YESNO enable caching {yes,no} (default: yes)
-o cache_timeout=N sets timeout for caches in seconds (default: 20)
-o cache_X_timeout=N sets timeout for {stat,dir,link} cache


[akhkharu]

Спасибо за совет, кажется после включения компрессии стало немного побыстрее. В любом случае, похоже, что проблемы возникают из-за того, что первое сканирование
проекта происходит на сервере. Попробую отсканировать локально и закачать на сервер папку nbproject/.

[PavelRadaev]

а база на проект общая для всех разработчиков? :)

[PavelRadaev]

БД всмысле

[vorob]

Как вам удобнее. Можно без проблем обойтись одной, можно приложение настроить, чтобы для каждого разработчика подхватывало различный dsn.