форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форумы OpenNET: Виртуальная конференция (Public)
Изначальное сообщение		[ Отслеживать ]

"Subversion"

Сообщение от GHopper (ok) on 13-Окт-08, 08:36

Здравствуйте! Ситуация сейчас: есть веб-сервер с виртуальным хостом shomeVirtualHost. На сервере поднят ftp. Есть три пользователя - программист, верстальщик и ведущий. Пользователи по протоколу ftp коннектятся на сервер, chroot-тятся на корень shomeVirtualHost и делают там свои дела. Все чудно, но есть проблема совместного доступа. Поднял subversion-1.4.6_1, настроил, разобрался - все норм. Проблема в том, что Subversion хранит репозитарии в сжатом виде (ну или в каком-то своем зашифрованном), что не позволяет настроить Apache прямиком на репозитарий. Если раньше люди работали с файлами и сразу видели результат своей работы, то теперь для этого им придется поднимать локальный веб-сервер, старый веб-сервер превращается в sebversion-сервер. Это не самое лучшее решение, т.к. не всем дано администрировать веб-сервера. По итогу хочу решение, которое позволит пускать пользователей на сервер и решит проблему совместного доступа. При этом в общем репозитарии должны быть файлы, которые передаются веб-сервером клиенту, т.е. при выполнении svn commit веб-страничка меняется в соответствии с принятыми изменениями. Вот. Как у нормальных людей все это работает?

Высказать мнение | Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Subversion"

Сообщение от geekkoo (??) on 13-Окт-08, 09:12

>Здравствуйте! >Ситуация сейчас: есть веб-сервер с виртуальным хостом shomeVirtualHost. На сервере поднят ftp. >Есть три пользователя - программист, верстальщик и ведущий. Пользователи по протоколу >ftp коннектятся на сервер, chroot-тятся на корень shomeVirtualHost и делают там >свои дела. Все чудно, но есть проблема совместного доступа. > >Поднял subversion-1.4.6_1, настроил, разобрался - все норм. Проблема в том, что Subversion >хранит репозитарии в сжатом виде (ну или в каком-то своем зашифрованном), >что не позволяет настроить Apache прямиком на репозитарий. Это в каком смысле? mod_dav_svn как раз и позволяет нстроить Apache прямиком на репозитарий. >Если раньше люди >работали с файлами и сразу видели результат своей работы, то теперь Ну, период психологической ломки неизбежен, поскольку им так или иначе придется отвыкать от работы с файлами и учить разные команды типа svn commit, update, add ... >для этого им придется поднимать локальный веб-сервер, старый веб-сервер превращается в >sebversion-сервер. Это не самое лучшее решение, т.к. не всем дано администрировать >веб-сервера. > так что именно нужно? Доступ к репозитарию не через файловую систему и без http? Есть ещё svn+ssh, такой вариант разобран в Subversion Book. >По итогу хочу решение, которое позволит пускать пользователей на сервер и решит >проблему совместного доступа. При этом в общем репозитарии должны быть файлы, >которые передаются веб-сервером клиенту, т.е. при выполнении svn commit веб-страничка меняется Какая веб страничка? Договорились же без http? >в соответствии с принятыми изменениями. > >Вот. Как у нормальных людей все это работает? Примерно вот так - http://www.samag.ru/cgi-bin/go.pl?q=articles;n=11.2005;a=06

Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	2. "Subversion"
	Сообщение от GHopper (ok) on 13-Окт-08, 10:44
	Хорошо! Настроил доступ к репозитарию через Apache. Теперь по http://HOST/svn/PROJECT/ открывается страничка "Revision N: /" и репозитарий находится на http://HOST/svn/PROJECT. Физически репозитарий у меня находится в /usr/local/www/PROJECT, рядом с другими виртуальными хостами. Как теперь настроить Apache так, чтобы отображались странички из репозитария PROJECT? Если настроить virtualhost на PROJECT, то открывается дерево файлов из папки, а как сделать, чтобы отображалась страничка?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	3. "Subversion"
	Сообщение от const (??) on 13-Окт-08, 13:21
	В репозитории есть каталог hooks с примерами. Сделай отдельный каталог и в post-commit делай svn update этого каталога. Веб-сервер пусть туда смотрит.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	4. "Subversion"
	Сообщение от GHopper (ok) on 13-Окт-08, 13:28
	>В репозитории есть каталог hooks с примерами. Сделай отдельный каталог и в >post-commit делай svn update этого каталога. Веб-сервер пусть туда смотрит. Оно! Примного благодарен! Есть проблема с правами... но думаю сам разберусь.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	5. "Subversion"
	Сообщение от PavelR (??) on 14-Окт-08, 07:59
	>>В репозитории есть каталог hooks с примерами. Сделай отдельный каталог и в >>post-commit делай svn update этого каталога. Веб-сервер пусть туда смотрит. > >Оно! Примного благодарен! Есть проблема с правами... но думаю сам разберусь. В корне неверная позиция. Не правильно делать коммит на изменение каждой строки текста или каждой буквы, чтобы увидеть результат своей деятельности в вэб-браузере. Ты так зае-шь в корень всех, программистов, верстальщиков, всех. Правильно сделать им свои рабочие области, чтобы они с ними работали как и раньше по своему любимому протоколу (FTP/SMB/в консоли/итд), и чтобы изменения файлов из рабочих области через Subversion вливались друг к другу. Ну и отдельную релизную рабочую область, в которой менеджер будет показывать заказчику прогресс вашего труда. -------------- На изменение каждой строки делать коммит - бред.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	6. "Subversion"
	Сообщение от GHopper (ok) on 14-Окт-08, 08:17
	поработал денек - меня самого уже задолбало каждый раз коммититься! Давайте-ка поподробнее, как все-таки грамотно все это сделать? Есть Программист,Верстальщик и Ведущий. Для каждого делаю отдельный VirtualHost и каждому даю ftp-доступ в корень. Они там работаю, правят все, что надо, а потом некто ГлобальныйАдмин запускает svn commit на каждом проекте и все сливается в единое место. Разрешение конфликтов также лежит на ГлобальномАдмине, который может и не шарить ни в программировании, ни в верстке, ни в управлении. А если у нас программистов несколько, и им всем приспичит вносить изменения в один файл mostPopularFile.inc. Тогда они очень скоро морды друг другу набью, т.к. у них постоянно будут пропадать данные. Что-то я не совсем понимаю как правильно организовать работу группы человек. Единственное более-мене приемлемое решение - у каждого поднимать локальный веб-сервер и каждому участнику проекта делать checkout в корень виртуального хоста, а потом уже коммититься по получению каких-либо ощутимых результатов. Но вот мысль о том, что придется поднимать у каждого локальный веб-сервер напрягает...
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	7. "Subversion"
	Сообщение от const (??) on 14-Окт-08, 09:45
	>Ну и отдельную релизную рабочую область, в которой менеджер будет показывать заказчику >прогресс вашего труда. > >На изменение каждой строки делать коммит - бред. Верно. Тот фокус с post-commit, что я выше описал - это как раз для "релизной области".
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	8. "Subversion"
	Сообщение от GHopper (ok) on 14-Окт-08, 10:19
	Так по итогу как организовать работу группы людей?!
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	9. "Subversion"
	Сообщение от PavelR (??) on 14-Окт-08, 10:32
	>Так по итогу как организовать работу группы людей?! каждый сам коммитит и резолвит свои конфликты.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	10. "Subversion"
	Сообщение от geekkoo (??) on 14-Окт-08, 13:16
	>Так по итогу как организовать работу группы людей?! Ты как-то превратно представляешь себе работу с VCS. Есть отдельная рабочая копия с репозитария в файловой системе, с которой работает каждый из "соавторов". При необходимости сделать изменения доступными всей группе, каждый из соавторов публикует свои изменения средствами commit, попутно проходя (если понадобится) через процедуру разрешения конфликтов. "У нас нет для вас других писателей, товарищ Фадеев" (с)
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	11. "Subversion"
	Сообщение от GHopper (ok) on 14-Окт-08, 13:28
	>>Так по итогу как организовать работу группы людей?! > >Ты как-то превратно представляешь себе работу с VCS. Есть отдельная рабочая копия >с репозитария в файловой системе, с которой работает каждый из "соавторов". >При необходимости сделать изменения доступными всей группе, каждый из соавторов публикует >свои изменения средствами commit, попутно проходя (если понадобится) через процедуру разрешения >конфликтов. > >"У нас нет для вас других писателей, товарищ Фадеев" (с) т.е. нужно для каждого поднимать локальный веб-сервер?
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	12. "Subversion"
	Сообщение от geekkoo (??) on 14-Окт-08, 13:33
	>[оверквотинг удален] >> >>Ты как-то превратно представляешь себе работу с VCS. Есть отдельная рабочая копия >>с репозитария в файловой системе, с которой работает каждый из "соавторов". >>При необходимости сделать изменения доступными всей группе, каждый из соавторов публикует >>свои изменения средствами commit, попутно проходя (если понадобится) через процедуру разрешения >>конфликтов. >> >>"У нас нет для вас других писателей, товарищ Фадеев" (с) > >т.е. нужно для каждого поднимать локальный веб-сервер? Не нужно! Есть команда svn commit -m ''
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	15. "Subversion"
	Сообщение от GHopper (ok) on 14-Окт-08, 14:26
	svn commit -m '' - не вариант. Предположим верстальщику нужно подобрать правильный цвет на бэкграунд некоторой таблички. svn update правит svn commit правит svn commit правит svn commit При этом "правит" он лишь шесть символов, зато приходится каждый раз переключаться на консоль (ну или юзать клиент) и ждать коммита. Это его быстро сведет с ума. Использовать "NFS, CIFS, SSH или что угодно ещё" - не решается проблема совместног доступа к файлам. Как и в старые-добрые времена при доступе чере FTP - все быстро и удобно, но информация в совмесно-используемых файлах часто теряется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	16. "Subversion"
	Сообщение от const (??) on 14-Окт-08, 15:45
	>Использовать "NFS, CIFS, SSH или что угодно ещё" - не решается проблема >совместног доступа к файлам. Как и в старые-добрые времена при доступе >чере FTP - все быстро и удобно, но информация в совмесно-используемых >файлах часто теряется. А зачем бросаться из крайности в крайность? "NFS, CIFS, SSH или что угодно ещё" - для доступа разработчика к _своему_ каталогу на веб-сервере. Это никак не отменяет необходимости VCS.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	17. "Subversion"
	Сообщение от geekkoo (??) on 14-Окт-08, 17:22
	>[оверквотинг удален] >svn commit >правит >svn commit >правит >svn commit > >При этом "правит" он лишь шесть символов, зато приходится каждый раз переключаться >на консоль (ну или юзать клиент) и ждать коммита. Это его >быстро сведет с ума. > Слушай, я не психиатр - сойдут твои пользователи с ума или нет - мне по барабану. А тебе, между делом, стоит разобраться - какую именно задачу ты решаешь и правильно ли ты ее себе представляешь. А не кидаться сразу в сабвершены и VCS. Я вот после 15 постов так и не понял, чего же тебе надо. На прямо поставленные вопросы ты не отвечаешь, вместо этого задаешь свои. Вообщем, посторайся в течении суток больше ничего не писать, а сядь и подумай. >Использовать "NFS, CIFS, SSH или что угодно ещё" - не решается проблема >совместног доступа к файлам. Как и в старые-добрые времена при доступе >чере FTP - все быстро и удобно, но информация в совмесно-используемых >файлах часто теряется.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	18. "Subversion"
	Сообщение от geekkoo (??) on 14-Окт-08, 20:39
	Щас только въехал, что именно требуется. Вы работаете над веб проектом и требуется, чтобы после каждого коммита в репозиторий, автоматически происходил бы update в другую рабочую директорию, откуда бы web-server мог бы их сразу опубликовать. Но это случай как раз разобран в Subversion FAQ один к одному: http://subversion.tigris.org/faq.html#website-auto-update
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	13. "Subversion"
	Сообщение от const (??) on 14-Окт-08, 14:03
	>т.е. нужно для каждого поднимать локальный веб-сервер? Если страх как не хочется этого делать, то можно поднять один веб-сервер, сделать на нём каталог для каждого разработчика, положить туда рабочую копию проекта и цеплять каталог на машину разработчика по NFS, CIFS, SSH или что угодно ещё.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

	14. "Subversion"
	Сообщение от PavelR (??) on 14-Окт-08, 14:04
	>[оверквотинг удален] >> >>Ты как-то превратно представляешь себе работу с VCS. Есть отдельная рабочая копия >>с репозитария в файловой системе, с которой работает каждый из "соавторов". >>При необходимости сделать изменения доступными всей группе, каждый из соавторов публикует >>свои изменения средствами commit, попутно проходя (если понадобится) через процедуру разрешения >>конфликтов. >> >>"У нас нет для вас других писателей, товарищ Фадеев" (с) > >т.е. нужно для каждого поднимать локальный веб-сервер? Для каждого нужна своя рабочая область, при этом не важно, будет ли она локальной или удаленной. В случае с отдельной локальной рабочей областью разрабы не смогут работать с общей БД, хотя и не факт что они будут работать с общей БД в случае рабочих областей на "удаленном"/выделенном веб-сервере.
	Высказать мнение | Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить	Индекс форумов | Темы | Пред. тема | След. тема
Оцените тред (1=ужас, 5=супер)? [ 1 | 2 | 3 | 4 | 5 ] [Рекомендовать для помещения в FAQ]