Subversion для контроля версий - PullRequest
Новая
       8

Subversion для контроля версий

3 голосов
/ 19 апреля 2010

Я работаю над приложением, основной целью которого было бы обеспечение управления исходным кодом. Моя идея состоит в том, чтобы использовать SVNKit для извлечения файлов и регистрации. Однако, работая с SVNKit, я понял, что у него нет скорости, которую я искал. Например, всякий раз, когда разработчики создают запрос ChangeRequest, который может включать изменения в 3-40 файлах, мне приходится создавать структуру каталогов, распределенную по 32 папкам. Это занимает около 50 секунд. Другой пример: после создания запроса на изменение разработчики могут добавлять файлы в запрос. Копирование даже одного файла из Trunk в ответвление занимает около 6-7 секунд. У меня вопрос, был ли у кого-нибудь подобный опыт, и что вы делали для улучшения производительности? Кроме того, мой подход правильный?

ПРИМЕЧАНИЕ: я использую протокол "http" и не могу использовать протокол "svn".

Ответы [ 3 ]

1 голос
/ 19 апреля 2010

Обычно SVNKit - это полная Java реализация subversion. И да, он намного медленнее, чем родной. Поэтому, если вы не ограничены только кодом Java Only, вы можете попробовать:

  • Использовать собственный SVN C API.
  • Использовать привязки SVN Java

Для получения дополнительной информации читайте: http://svnbook.red -bean.com / ru / 1.5 / svn.developer.usingapi.html коробка "SVNKit Versus Javahl"

Также обратите внимание ... протокол практически не влияет на производительность (действительно).

0 голосов
/ 19 апреля 2010

Это действительно не так много информации, в основном это слухи:

  • У SVN есть серьезные проблемы с масштабированием, когда число пользователей состоит из трех или четырех цифр. Люди, как правило, берут копии, и есть некоторые плохие варианты масштабирования.
  • Коммерческий продукт PerfForce не имеет проблем с масштабированием.
  • GIT не имеет проблем с масштабированием, хотя его легко испортить.
  • Mercurial хорошо работает и хорошо масштабируется. Затем появляется чей-то высокопоставленный конек и проверяет очень большие файлы. Также есть проблемы с CR / LF.

Это все слухи.

0 голосов
/ 19 апреля 2010

Я не знаю деталей (что это за файлы, какие у них большие файлы?), Но SVN не такой медленный

Мы используем его здесь и отлично работаем.

Просто любопытно, где находится ваш SVN-сервер? Внутри или за пределами вашей сети? Это может быть медленным из-за сети?

...