Доброго времени суток! 
Подскажите, как насроить svn  чтобы он размещал .svn директории не в директории проекта?

зачем ?!!!

На сколько я знаю svn определяет факт "подконтрольности" артифактов именно по такой директории (точнее по той информации, которая там храниться) - т.о. наверное никак.


Действительно, зачем?

Наверное ответ будет таким: "Что бы, когда я отдаю, кому-нибудь свой проект, там не было много-много этих жутких папочек, которые вручную удалать очень долго".

Не, не полный чайник  Проект разрабатывается на удаённом сервере, по старинке: по ssh в vi, объяснить приимущества работы в системе контроля версий и IDE не удалось. Была идея примонтировать проект на через sshfs, поднять локально svn. чтобы те, кто хотят работать через svn работали, а смонтированая папка на сервере была рабочей версией юзера team, которая апдейтилась бы по тригеру после каждого комита. Естественно наличие папок .svn там никто не одобрит... 

Это сообщение отредактировал(а) patt - 23.9.2010, 13:06

и никаких папок .svn

если не удалось, то не тратьте наше время.

patt, 

Да это я так... Поглумиться решил , я и сам, то далеко не специалист  .

Несколько раз прочитал, но так и не понял, почему наличие папок .svn - это плохо?
Вот есть у меня группа разработчиков, есть у меня "центральный" сервер, на котором запущен Subversion, и установлен сервер непрерывной интеграции (конктретно в моем случае это Hudson CI), "включен" у меня на сервере непрерывной интеграции триггер на обновления svn-репозитория, который, при каждой ревизии делает svn up для некоторой рабочей копии. И? Где кому что мешает  ?

Нужно тебе получить проект - пожалуйста svn co и открывай его чем хочешь, хочешь vim, хочешь IDE (единственный нормальный способ работы, на мой взгляд).
Не хочешь писать svn co - копируй его себе по ssh (лично я не считаю это "нормальным" решением).

Ну или смонтировать, рабочую копию, как сетевую папку (хотя тоже не понятно зачем).
Но, что то я сути проблемы не уловил.


Т.е. есть такие, которые не хотят работать с svn   ?! Или, о ужас - боюсь даже спросить, с системами контроля версий вообще   ?!

Так и не понял, почему их там никто не одобрит...

Gluttton, не тратьте свое время.
существуют ситуации (напр. при хорошем бэкапе), когда преимущества внедрения контроля версий не покрывают недостатки потерянного времени.
насчет IDE - то же самое. 

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

В общем ситуация такая: я и ещё пара человек пришел на фирму где системы контроля версий плотно никогда не юзались, все работают через ssh, так привыкли и менять осбо ничего не хотят, а я разработку без VCS представляяю слаобо (постоянно бэкапы делать, как отслеживать изменения проекта, к кому обращаться если есть вопросы по коду, конфликт при работе с файлами и т.д.) поэтому решил неофициально поднять на своей машине svn. В общем нужно чтобы на работу остальных это не повлияло. 
Экспорт не подходит т.к. изменения сделаные на сервере должны попадать в svn, накатывать рабочий проект на локальный который в svn как отдельная копия тоже не вариант т.к. канал слабоват. Какие ещё могут быть варианты? может rsynk?

patt,  удачи.

Добавлено @ 15:20

ха ха ха. а говорил - романтик.
как вы это себе представляете: рядом со всеми будете комменты к коду и коммиты вручную делать ?
т.е. замена одного геморроя - другим. прозрачно для предыдущей схемы работы, без официального внедрения не пойдет.
если будете rsync применять, то сервер будет забиваться ненужным барахлом и нагрузкой на сеть.
как будете конфликты при автоматических коммитах решать ? 
удачи в ненужной борьбе с ненужными ветряными мельницами.

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

Добавлено @ 15:26

бекапы делать надо и хранилищам. регулярно проверяя корректность (в случае svn - svnadmin verify) и реставрацию. а то набэкапите там мусора...

Это сообщение отредактировал(а) bilbobagginz - 23.9.2010, 15:27

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

чтобы показать как это работает не надо извращаться: установить вирт. машину линукс, настроить по интернетовским рецептам, и подключить тест-клиентов. а чтобы показать чем это лучше - надо это понимать самому ;-)
или я чего-то недопонял ?

просьба: не надо цитировать все сообщение. это удлинняет всю ветку без нужды. 


Это сообщение отредактировал(а) bilbobagginz - 23.9.2010, 17:26

Угу. У меня таким образом построена целая сетка: ПК для разработки, ПК для сервера непрерывной интеграции и ПК для развертывания (web-приложения). Таскаю с собой три образа в "кармане", и где бы я не сел работать, для того, что бы мне поднять свою сетку мне нужен только лишь VirtualBox (а для связи с внешним миром я использую openVPN).

patt, не уверен, но мне кажеться, что вся сила svn'а (в прочем как и любой другой системы контроля версий, да и не только, а любой технологии вообще) может проявиться тогда, когда эту технологию приминяют тотально. И смысла, делать репозиторий, с которым будет работать только часть команды, я не вижу, т.к. другая часть команды сведет на нет все выгоды от его использования.
Далеко ходить не нужно - кто будет за "вторую часть команды" конфликты разгребать? Или же зачем мне смотреть дельты между ревизиями, если я знаю, что могут быть ещё изменения, которые "не под контролем"?
Но это я так - тереотезирую  . Безусловно виднее вам, но я думаю, что выход здесь только один: