Комментарии 61
а freeware аналогов ExpanDrivе нету?
p.s. Молодец. Ждем продолжения.
p.s. Молодец. Ждем продолжения.
+4
Dokan SSHFS
Как установить тут: blog.azomazo.ru/2009/02/ssh-windows.html
…
После установки запускаем программу, и вписываем настройки сервера, к которому подключаемся, и указываем букву диска. После подтверждения в трее появится иконка программы, говорящая что диск примонтирован. Все можно по нему бегать любой программой.
…
Но опятьже на таком диск с SVN при помощи, например, TortoiseSVN работать не получается…
Как установить тут: blog.azomazo.ru/2009/02/ssh-windows.html
…
После установки запускаем программу, и вписываем настройки сервера, к которому подключаемся, и указываем букву диска. После подтверждения в трее появится иконка программы, говорящая что диск примонтирован. Все можно по нему бегать любой программой.
…
Но опятьже на таком диск с SVN при помощи, например, TortoiseSVN работать не получается…
+2
У нас похожая структура. Только диск подключается не софтом, а самой виндой как сетевой. Проекты доступны по адресу projec.username.company.com. Работает всё на FreeBSD сервере. У каждого на сетевом диске список папок с проектами. Каждая папка автоматом монтируется в поддомен.
0
Скажите, а согласно Вашей системе юрлов, username.company.com на что указывает?
Дело в том, что username.projec.company.com позволяет при удалени младшего сегмента projec.company.com видеть версию репозитория)
Дело в том, что username.projec.company.com позволяет при удалени младшего сегмента projec.company.com видеть версию репозитория)
0
test.username.company.com -> /users/username/www/test/
username.company.com -> /users/username/www/ — корень рабочей директории пользователя. В ней лежат директории с проектами. Тоесть у каждого разработчика своя копия проекта. Только база данных общая. После окончания задачи на каком либо из проектов идет коммит в репозиторий, который лежит на отдельной машине. Если нужно вылить проект на продакшн, то жмется спец кнопка, которая запускает скрипты экспорта. С её же помощью можно посмотреть текущую версия на живом сервере проекта и откатить исходники при необходимости.
username.company.com -> /users/username/www/ — корень рабочей директории пользователя. В ней лежат директории с проектами. Тоесть у каждого разработчика своя копия проекта. Только база данных общая. После окончания задачи на каком либо из проектов идет коммит в репозиторий, который лежит на отдельной машине. Если нужно вылить проект на продакшн, то жмется спец кнопка, которая запускает скрипты экспорта. С её же помощью можно посмотреть текущую версия на живом сервере проекта и откатить исходники при необходимости.
0
А зачем именно workaround=rename? Я давно монтирую так директории и проблем с SVN не встречал, может быть потому что я один монтирую эту папку и никто другой не «мешает» мне? :)
0
У меня вот какой вопрос возник.
Допустим над проектом (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, подгоняют свои проекты под этот общий итог?
Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
Допустим над проектом (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, подгоняют свои проекты под этот общий итог?
Возможно я не совсем разобрался в самой идее и поэтому надеюсь на вашу помощь.
0
ну, когда один из них сделал то, что ему было нужно, он делает comit, остальные уже могут сделать update и получить результат его работы в свою версию.
0
Каждый пользователь делает 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 можно также автоматизировать.
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 можно также автоматизировать.
0
У них независимые копии проекта, а репозиторий один.
Посмотреть итог работы этих троих можно сделав пост-хук-коммит, который бы обновлял например: /var/www/build.example.com/project/, тогда по адресу build.project.example.com будет находиться самая последняя версия проекта.
Если в репозитории по ветке на каждого разработчика, то чтобы посмотреть результат работы нужно будет делать merge между ветками.
Посмотреть итог работы этих троих можно сделав пост-хук-коммит, который бы обновлял например: /var/www/build.example.com/project/, тогда по адресу build.project.example.com будет находиться самая последняя версия проекта.
Если в репозитории по ветке на каждого разработчика, то чтобы посмотреть результат работы нужно будет делать merge между ветками.
+1
Просто именно описание того что есть некоторый магический build.example.com не было в статье. И я хотел узнать как у вас это делается.
Спасибо за ответ.
Спасибо за ответ.
0
Где-то недавно проскакивала статья о создании хуков: adw0rd.ru/2009/subversion-hooks/
0
Спасибо за ссылку.
Мне просто не очень понравилась идея хуков.
Вот некоторый пример.
Пусть все будет как и описано в этом комменте ( 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
Но при этом всегда есть, актуальная что-ли, версия проекта.
Еще в вашем описании среды никак не описана БД. Многие проекты ее используют. Понятно что для каждого из пользователей необходима свою БД.
В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(
Мне просто не очень понравилась идея хуков.
Вот некоторый пример.
Пусть все будет как и описано в этом комменте ( 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
Но при этом всегда есть, актуальная что-ли, версия проекта.
Еще в вашем описании среды никак не описана БД. Многие проекты ее используют. Понятно что для каждого из пользователей необходима свою БД.
В любом случае я ваш метод не критикую, просто сейчас в нашей компании пытаемся внести большую организацию в веб-разработку и ваша статья очень кстати. И никак не могу переложить на наши внутренние процессы вашу организацию. :(
0
>Но вот что мне не нравится больше всего, при продолжении работы программист и верстальщик делают 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 в общую ветку.
>в интеграционном проекте 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 в общую ветку.
+1
> Почему после коммита обоих в 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
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
—
> А если не сольются, то второму надо будет сначала апдейт сделать, потом конфликты поправить.
согласен. немного стормозил. изменения сольются, но в любом случае если использовать предложенный 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
По такому адресу сам разработчик и все члены команды получают доступ к наработкам друг друга.
—
0
>pr1.project.example.com/trunk или pr2.project.example.com/trunk получаешь в рабочую копию данные из одного репозитория?
Я так понимаю, что здесб лежат рабочии копии программистов. Т.е. это не свн. Возможно я ошибаюсь.
Я так понимаю, что здесб лежат рабочии копии программистов. Т.е. это не свн. Возможно я ошибаюсь.
0
Разобрался.
0
Под линукс очень удобно использовать automount sshfs — вот подробная статья по настройке. Это по сути «монтирование по требованию».
+3
а в чем конкретно проблема с SVN и samba?
у нас аналогичная структура и все прекрасно работает и из консоли и через TortoiseSVN
т.е. нужда в ExpanDrivе отпадает
у нас аналогичная структура и все прекрасно работает и из консоли и через TortoiseSVN
т.е. нужда в ExpanDrivе отпадает
+1
У нас не получалось закоммитить файл, который находился не в version control.
В то время как раз шло активно обсуждение в мейл-листе самбы на эту тему www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html
Сейчас может быть ситуация с выходом новых версий изменилась.
У вас какая версия svn и самбы?
В то время как раз шло активно обсуждение в мейл-листе самбы на эту тему www.nabble.com/-PATCH--Working-copy-on-Samba-share-td19606426.html
Сейчас может быть ситуация с выходом новых версий изменилась.
У вас какая версия svn и самбы?
0
svn и 1.4.х и 1.5.х, про самбу точно не знаю, но такая система в нашей конторе уже сильно больше года работает
0
У нас в офисе настроено так же, как описано в статье. И тоже существует проблема с рабочими копиями на самбе. Причем эта проблема проявляется у разработчиков, которые пользуются линухом. Под виндой все нормально. Проблема (предположительно) заключается в несоответствии UID и GID серверного (из-под которого открывается досутуп к шаре) и локального (который пытается примонтировать) пользователей. Поэтому одно из решений, которое у нас успешно работает — изменить локальный UID/GID, приведя в соответствии с серверными. Я же принципиально пользуюсь sshfs, хотя испытываю дискомфорт от тормознутости.
Третья альтернатива — NFS, которая намного лучше подходит линух-пользователям, чем самба.
Третья альтернатива — NFS, которая намного лучше подходит линух-пользователям, чем самба.
0
Хорошая схема, ее много лет назад обсуждали в инете и конфах, теперь думаю она с теми или иными вариациями у очень многих работает.
0
Странно, но у TortoiseSVN на виндовых машинах никогда проблем с шарами самбы проблем не было.
0
Eclipse + Subclipse — проблем на винде, линукс и макосе в шарами самбы проблем не имеет.
0
А какой IDE, если не секрет? Eclipse?
-2
Спасибо за ExpanDrivе, не знал про нее. А бесплатные аналоги есть?
-2
НЛО прилетело и опубликовало эту надпись здесь
Похоже, совсем не используется удаленная отладка?
0
Просто модуль для пхп добавить.
-1
Я не у вас спрашивал, но раз уж вы считаете это тривиальным, опишите какой модуль и как его следует настроить, чтобы множество разработчиков могло отлаживать и не блокировать работу друг-друга.
+1
А разве одновременно возможна лишь одна сессия дебага? о_О
я в phped втроенный юзаю, как вариант от zend'a отладчик или xdebug.
я в phped втроенный юзаю, как вариант от zend'a отладчик или xdebug.
0
По-моему нет, но настройка xdebug.remote_host предполагает один постоянный хост.
Просто интересно посмотреть как админ выпутается.
Просто интересно посмотреть как админ выпутается.
0
ой ли?
.htaccess:
===
php_value xdebug.remote_host %my-remote-ip%
===
Понятное дело, нужные опции для .htaccess из конфига Апача должны быть включены.
.htaccess:
===
php_value xdebug.remote_host %my-remote-ip%
===
Понятное дело, нужные опции для .htaccess из конфига Апача должны быть включены.
0
А если двое программистов работают над одним проектом (каталогом)?
Наверное через SetEnvIf можно
Наверное через SetEnvIf можно
0
Боюсь, что ОДНА физическая директория для разработки проекта несколькими программистами — это ОЧЕНЬ тесно и плохо (при активной разработке и близких задачах). Причем считаю так, основываясь и на своем, отрицательном опыте в этом плане.
0
Ну так и что? они все равно так работают. В один файл index.php, в который с помощью modrewrite сгоняются все запросы. Это модно.
До тех пор пока не встает вопрос об отладке.
До тех пор пока не встает вопрос об отладке.
0
Приведу простейший пример: разрабатываются одинаково подключаемые одновременно модули, и для контроля «всё ли происходит как надо» оба программиста в своём коде добавляют var_dump(). После чего получаем взаимную феерию с, иногда, тяжкими последствиями.
0
Неважно что там у вас было на практике. Приложение УЖЕ построено наихудшим образом из кусков опенсорсных и самодельных велосипедов.
Предложите лучше красивую схему отладки и взаимодействия.
Предложите лучше красивую схему отладки и взаимодействия.
0
Вот и у нас такая же проблема — хотим использовать такую схему, но скорее всего нельзя будет использовать отладку одновременно для нескольких клиентов. Во-первых, у нас есть клиенты Windows (PHPEd, dbg) и Linux (Netbeans, xdebug), а прикрутить два модуля одновременно вряд ли получится. Во-вторых, даже если учитывать только клиентов Netbeans, сомневаюсь, что Netbeans умеет работать с отладочным прокси-сервером.
Жаль, но без отладки никак.
Жаль, но без отладки никак.
0
Похоже, что в случае WiFi этот способ использовать комфортно не получится: Netbeans постоянно подвисал при скроллировании дерева проекта и при прочих операциях с файлами, а у нас был всего лишь один клиент…
0
А как монтировали директорию?
0
Как было сказано в топике, через sshfs с настройкой workaround=rename
0
Попробуйте примонтировать с использованием компрессии или кэшированием:
...
-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
0
а база на проект общая для всех разработчиков? :)
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Организация среды веб-разработки