Есть команда разработчиков и общий проект. Задача организовать комфортную работу над проектом. Условия:
1. Разработчик должен иметь возможность отладки своей части изменений в режиме реального времени.
2. Разработчики должны работать над проектом параллельно. Все изменения разработчиков контролируются системой контроля версий.
3. Существует центральный репозиторий в котором объеденены все наработки разработчиков.
4. (желательно) Уйти от необходимости поднимать HTTP сервера на машинах разработчиков.

Сначала расскажу как мы начали решать эту задачу и с какими проблемами столкнулись.
1. Поставили отдельный сервер в офисе на котором подняли HTTP сервер и прочие необходимые сервисы (PHP, MySql и т.п.)
2. На сервере создали виртуальные хосты для каждого разработчика + мастер хост в котором предполагаеться располагать центральный репозиторий.
3. Каталоги, которые "слушают" виртуальные сервера мы расшарили для разработчиков. По факту монтирования этих каталогов на свои машины разработчики получили возможность редактировать свои репозитории с возможностью видеть все изменения. На первый взгляд, задача почти решена. Разработчики работают со своей копией проекта, имеют возможность отладки в режиме реального времени и не нуждаються в развертывание серверов на своих машинах. Но тут возникла проблема.
4. Мы установили GIT репозиторий и попытались наложить на всю нашу инфрастрктуру систему контроля версия и тут начались проблемы. Напомню, что разработчики локально работают в каталог, который реально находиться на сервере, а локально мы имеем лишь монтированный ресурс. Так вот GIT отказался держать локальную версию репозитория в монтированном каталоге. Конкретных ошибок он выводить не стал, но ненормально долго работал и начинал выводить ошибки типа "коммит фейл" и т.п. Проверили - проблема 100% вызвана тем, что целевой каталог клонирования не реальный, а монтированный.

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

Все проблемы вызваны пунктом 4. А я не понимаю, зачем этот пункт нужен.
Без этого пункта все выливается в банальное использование репозитория.

30-ого закончили на том, что вроде как SVN в отличие от GIT не давиться монтированными каталогами. Обидно отказываться от GIT'а из-за такой, вроде как мелочи, но похоже придется.


Можно поподробнее?


Спасибо, кэп ) 

 Попробуй mercurial, если требуется распределенная система.

 А в чем вопрос?

=) О каком репозиторие речь? Обычный файловый в котором разработчики регулярно перетирают файлы?

BuShaRt, я не понял, что ты имеешь ввиду под "обычным файловым" и как там можно перетереть файлы, если система VCS за этим следит.

Absinthe, 
Так 4-ый пункт как раз и говорит о наложение VCS на инфраструктуру и создание репозитория. Я вашу фразу не как иначе понять не могу: "Если у Вас не получается водить машину, то забейте на нее, ведь вам нужно просто сесть за руль и поехать"...

 А я прочитал ее как "4. (желательно) Уйти от необходимости поднимать HTTP сервера на машинах разработчиков.". 
Зачем? На локальной машине это удобнее, т.к. гибче и проще.

И никаких вышеописанных проблем с гитом не будет.

Это сообщение отредактировал(а) Absinthe - 2.1.2012, 16:41

Почему бы не использовать синхронизацию локальной копии проекта с удаленным сервером? Все современные ИДЕ поддерживают эту возможность. В итоге не будет проблем с гитом и сервер будет нагружен намного меньше.

 При количестве человек больше одного - не прокатит.

У каждого разраба свой вирт. хост - в чем проблема?

s0lman, а, мне показалось, что так файлы хранить хочешь 

Ну тут либо у каждого разраба свой хост, либо используют свой. Я, например, даже в локальный сервер из IDE по ssh файлы отсылаю - т.к. IDE на линуксе плохо работает, а на винде плохо работает вебсервер.

На сколько быстро срабатывает синхронизация? Мне необходим моментальный эфект (технически он возможен т.к. сеть локальная), но вот срабатывает ли синхронизация "из коробки" в момент сохранения файла?

Absinthe, 
Тот-то мы друг друга понять не можем =) мы о разных 4-ых пунктах.. Централизованный сервер нужен, для целостности всех настроек проекта. По сути крупные проекты очень зависимы от настроек сервера и хранимых в базах данных и кеше данных. Синхронизировать инфраструктуру проекта достаточно хлопотное занятие, поэтому хотелось бы иметь минимальное кол-во серверов, которые необходимо настраивать. 

Моментальный эффект достигается. В нетбинсе заливаются файлы автоматически при сохранении (вроде только так, я им не пользуюсь), в шторме более расширены настройки. Также ИДЕ может отслеживать внешние изменения файлов и заливать на удаленный хост (например, если любишь апдейтиться из консоли).

Добавлено через 2 минуты и 21 секунду

Лично я юзаю шторм, ребята нетбинс, аплоадим файлы по самбе - линуксоиды-нетбинсники не жаловались 

 Вот эти 2 как раз плохо и работают. В качестве пруфа реквестирую скриншот: буду шрифты разглядывать. Они кривые - это не "работает", а издевательство. Особенности жабы(SWT) под линуксом.

 Пара секунд. Оно при каждом [cmd/ctrl]+[s] сохраняет на сервер.

 Это не нужно: есть встроенные более удобные средства.

Хз, с корявыми шрифтами мне еще и разу не приходилось сталкиваться (не первый год под линуксом)



на вкус и цвет, как говорится   

С NetBeans действительно есть серьезная проблема со шрифтами под Linux, не на всех дистрибутивах, но есть. Сейчас на работе Suse - с ней все в порядке, но вод под Ubuntu шрифты были ненормально крупными и как настроить их я так и не разобрался. Там проблема в том, что шрифты надо настраивать на уровне JRE, а для меня это темны лес (как показал поиск по Google, не для меня одного).

Это сообщение отредактировал(а) BuShaRt - 3.1.2012, 17:09

BuShaRt, под убунту средствами убунту эта задача нерешаема.

Absinthe, 
=) Ну раз пошел офф-топ, то позволю себе спросить как эта задача решаеться т.к. выяснить это не удалось

BuShaRt, задача автоматического аплоада из IDE на сервер?

Это сообщение отредактировал(а) Absinthe - 4.1.2012, 13:59

2-ой день работает по описанной в сабже схеме, заменив GIT на SVN. В целом, конечно не хватает плюшек GIT'a, но по сути основные необходимые функции SVN выполняет. Вероятней всего на этом и остановимся.

А разработчиков сколько всего?

На прошлой работе работал по аналогичной схеме (девелоперов было ~ 15) - сервер глючило адски.

BuShaRt, мне плюшки гита кажутся напрягающим неотключаемым(если отключить - теряется смысл гита) излишеством  Каждому свое.

s0lman, у нас 10 на одном проекте. Что значит глючило? Все одни и те же файлы правили одновременно и потом мержились трудно?

Это сообщение отредактировал(а) Absinthe - 6.1.2012, 15:21

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

После тестирования SVN выяснили, что он хоть и не падает от работы с такой инфраструктурой, но временами все равно глючит и всегда жутко тормозит. По факту выявления этой проблемы начали тестировать вышеизложенный вариант с синхронизацией каталогов т.е. файлы проекта хранились в двух местах одновременно: 1. (основной) это локальный каталог в который клонируем репозиторий. От сюда же делаем каммиты. 2. Примонтированный каталог, реально расположенный на сервере (с ним работает виртуальный хост). NetBeans действительно синхронизирует каталоги на лету, поэтому все работает на ура с любой системой контроля версий.

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

Добавлено через 1 минуту и 43 секунды
BuShaRt, а тестовый сервер и сервер с репозиторием у вас случайно не на одной машине?

Хммм... а кто отменял ветки для разработки и мержи с транком, после чего транк по крону синхронизирует каталоги и файлы на тестовый сервер.
А вот развёртывание дебажинга с удалённого сервера более не приспособлен что ли к IDE и не каждая его хавает. А вот с локальным нет проблем, !!! мало того на локальном каждый разраб может иметь не менее нужныъх инструментов встроенных в сервер или IDE (PHPUnit, Maven, Ant) ... то есть накладывается на проект ещё и описание настройки среды разработки и степень специализации разработчиков что не менее важно. 
Для целостности проекта кто отменял ежедневные, двудневные ... еженедельные сборки и тестирование сборок перед мержем с транком и тестовым сервером?

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

Это сообщение отредактировал(а) Sentox - 13.1.2012, 22:23

Sentox, тут видимо сначала был проект, а потом под него решили методологию подвести

 А какая разница, сервер удаленный или локальный, если дебажится через сокет?
Все популярные IDE это умеют.