Есть команда разработчиков и общий проект. Задача организовать комфортную работу над проектом. Условия:
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] сохраняет на сервер.

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