URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID9
Нить номер: 8559
[ Назад ]

Исходное сообщение
"SVN + большое кол-во файлов в проекте = тормоза при update etc."

Отправлено Nas_tradamus , 17-Дек-09 13:39 
Здравствуйте!

Используем Subversion 1.6, большинство программеров работает из под винды. У нас в проекте более 12000 файлов.

Если сделать через виндовый TortoiseSVN checkout/update - комп вешается буквально на несколько часов, из-за чего работать просто невозможно. Особенно трудно делать merge в таких условиях.

Кто сталкивался с такой проблемой? Есть ли способы ее решения без смены хранилища?

PS: менять хранилище на git/mercury нельзя - слишком много сил было потрачено на автоматизацию создания сборок из SVN.


Содержание

Сообщения в этом обсуждении
"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Вова , 17-Дек-09 14:49 
> Здравствуйте!
>
>Используем Subversion 1.6, большинство программеров работает из под винды. У нас в
>проекте более 12000 файлов.
>
>Если сделать через виндовый TortoiseSVN checkout/update - комп вешается буквально на несколько
>часов, из-за чего работать просто невозможно. Особенно трудно делать merge в
>таких условиях.

в виртуальной машине ставьте линух?


*@* ~ $ time svn co svn+ssh://svn.*/*/trunk  t2 >output 2>errors
real    2m46.118s
user    0m16.537s
sys     0m8.325s

*@* ~ $ du -sh t2
1.2G    t2

*@* ~ $ find t2 |wc -l
64909



"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Nas_tradamus , 17-Дек-09 18:07 
>[оверквотинг удален]
>*@* ~ $ time svn co svn+ssh://svn.*/*/trunk  t2 >output 2>errors
>real    2m46.118s
>user    0m16.537s
>sys     0m8.325s
>
>*@* ~ $ du -sh t2
>1.2G    t2
>
>*@* ~ $ find t2 |wc -l
>64909

Научить всех пользоваться юниксом нет возможности.
На ufs во FreeBSD полный checkout+revert занимает 40 минут примерно. На винде с NTFS часа 1.5-2.


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено svn , 17-Дек-09 16:22 
SVN тут ни при чём. Всё дело в количестве файлов. Попробуй FAT, или хотя бы выключить atime.

Ну и разумеется дефрагментация.


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Nas_tradamus , 17-Дек-09 18:08 
>SVN тут ни при чём. Всё дело в количестве файлов. Попробуй FAT,
>или хотя бы выключить atime.
>
>Ну и разумеется дефрагментация.

А что если у людей только 1 раздел с NTFS? Винда не рухнет, если отключить atime? И как это делается в винде? (пошел гуглить) :)


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Nas_tradamus , 18-Дек-09 12:59 
>>SVN тут ни при чём. Всё дело в количестве файлов. Попробуй FAT,
>>или хотя бы выключить atime.
>>
>>Ну и разумеется дефрагментация.
>
>А что если у людей только 1 раздел с NTFS? Винда не
>рухнет, если отключить atime? И как это делается в винде? (пошел
>гуглить) :)

В общем, atime отключается в реестре очень легко, не надо даже перезагружаться:


http://www.pctools.com/guides/registry/detail/50/


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Nas_tradamus , 18-Дек-09 14:08 
>[оверквотинг удален]
>>
>>А что если у людей только 1 раздел с NTFS? Винда не
>>рухнет, если отключить atime? И как это делается в винде? (пошел
>>гуглить) :)
>
>В общем, atime отключается в реестре очень легко, не надо даже перезагружаться:
>
>
>
>http://www.pctools.com/guides/registry/detail/50/

Не помогло. Update + revert делались около часа на рабочей копии с отключенным atime. Правда, последний раз эта рабочая копия апдейтилась примерно месяца 2 назад.


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено аноним , 18-Дек-09 17:06 
>Используем Subversion 1.6, большинство программеров работает из под винды. У нас в
>проекте более 12000 файлов.

Сразу могу сказать что под винду можете не надеяться получить что-то приемлимое. У нас 38000+ файлов, под Linux и FreeBSD на ноутбуках и рабочих станциях все летает. Относительно, конечно, т.к. SVN сама по себе очень неторопливая вещь для таких больших проектов, потому что при update, например, обходит все дерево - тем не менее, чекаут/update даже на нетбук более 10 минут не занимает.

>Кто сталкивался с такой проблемой? Есть ли способы ее решения без смены хранилища?

Ну тут либо смена хранилища, либо системы. А лучше и то, и то.

>PS: менять хранилище на git/mercury нельзя - слишком много сил было потрачено
>на автоматизацию создания сборок из SVN.

Если на автоматизацию сборок из SVN было потрачено много сил, вы уже что-то не так делаете. Ну значит будете тратить силы на апдейты по два часа, всего то. Как вариант можете потратить время на наболдашник для partial checkout.


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено Nas_tradamus , 18-Дек-09 18:00 
>[оверквотинг удален]
>>Кто сталкивался с такой проблемой? Есть ли способы ее решения без смены хранилища?
>
>Ну тут либо смена хранилища, либо системы. А лучше и то, и
>то.
>
>>PS: менять хранилище на git/mercury нельзя - слишком много сил было потрачено
>>на автоматизацию создания сборок из SVN.
>
>Если на автоматизацию сборок из SVN было потрачено много сил, вы уже
>что-то не так делаете.

Спасибо за советы. Но что же не так в автоматизации? Я имею в виду спец-софтину, которая собирает web-проект на указанном тестовом сервере из указанного бранча/транка. Нюансов - "стотыщмиллионов", которые пришлось учесть при ее проектировании.
Зато теперь все довольны - каждый программер может спокойно создать себе билд и отлаживаться на нем сколько влезет. QA-отдел вообще в восторге.

Это я к тому, что сменить хранилище нет возможности. Программеров увольнять за нежелание изучать Unix тоже нельзя: этих-то ели нашли.


"SVN + большое кол-во файлов в проекте = тормоза при update e..."
Отправлено аноним , 18-Дек-09 20:38 
>Спасибо за советы. Но что же не так в автоматизации? Я имею
>в виду спец-софтину, которая собирает web-проект на указанном тестовом сервере из
>указанного бранча/транка. Нюансов - "стотыщмиллионов", которые пришлось учесть при ее проектировании.

Ну это уж вам виднее. Я не могу себе представить что можно было наворотить, чтобы оно было гвоздями прибито именно к SVN.

>Это я к тому, что сменить хранилище нет возможности. Программеров увольнять за
>нежелание изучать Unix тоже нельзя: этих-то ели нашли.

Никто и не предлагал увольнять программеров. Если не можете ничего менять, миритесь с простоями.