Выбор сервера подверсии
Вот мой ...
function thousandCommas(num) {
num = num.toString().split('.');
var ints = num[0].split('').reverse();
for (var out=[],len=ints.length,i=0; i < len; i++) {
if (i > 0 && (i % 3) === 0) out.push(',');
out.push(ints[i]);
}
out = out.reverse() && out.join('');
if (num.length === 2) out += '.' + num[1];
return out;
}
4 ответа
Редактировать : После прочтения других ответов здесь я подумал, что должен упомянуть одну вещь. Если вы попробуете один сервер, репозитории, которые вы просите его обслуживать, не будут отличаться от репозиториев, которые вы запрашиваете у другого типа сервера.
Другими словами, если вы решите попробовать один сервер сейчас, вы можете переключиться на другой тип сервера позже, без потери ваших репозиториев. Конечно, рабочие копии и любые абсолютные внешние ссылки, которые вы сделали в своих проектах, должны быть изменены, но вы можете сохранить свои репозитории с историей и всем остальным.
Я установил VisualSVN Server , когда он был объявлен, и какое-то время был им вполне доволен.
Однако проблемы со скоростью заставили меня переключиться на основной сервер svnserve, который поставляется как часть пакета командной строки Subversion.
Основная проблема заключается в том, что я работаю с .NET, и я решил добавить несколько внешних ссылок Subversion в свои проекты.
Прежде всего, каждый проект, который я делаю в моей библиотеке классов, подписан моим ключом . Во-вторых, в качестве внешних ссылок были добавлены внешние сторонние библиотеки, такие как SQLite и NUnit .
Каждый проект имел свои собственные внешние ссылки. Я сделал это для того, чтобы иметь возможность создать новый проект приложения, а затем создать новые внешние ссылки на части моей библиотеки классов, которые мне нужны, и чтобы эти ссылки были полными. Если бы у моего решения библиотеки классов в .NET была одна внешняя ссылка для файла ключа подписи, и этот файл не был бы доступен как часть какого-либо отдельного проекта, но находился на диске вне всех проектов, но локально для моего решения, это было бы не сработали.
Итак, мое решение библиотеки классов содержит около 15-20 проектов, каждый из которых имеет хотя бы одну внешнюю ссылку на ключ подписи, все мои проекты данных имеют внешние ссылки на библиотеку SQLite, а библиотека модульных тестов имеет 4-5 внешних ссылок.
В итоге одно обновление на уровне решения, даже если у меня уже были все последние файлы, каталоги, все, заняло около 2 минут. Каждая отдельная внешняя ссылка занимала от 10 до 20 секунд, просто чтобы убедиться, что у меня есть нужная мне ревизия.
Когда я переключился на svnserve, эти 2 минуты сократились до примерно 3 секунд. Имейте в виду, что это местный трафик, поэтому, конечно, в Интернете все будет иначе. Проблема в том, что эти 2 минуты также были локальным трафиком.
Итак, хотя мне очень понравился интерфейс, который мне предоставил VisualSVN Server, включая возможность легко настраивать права доступа и пользователей, скорость, которую предоставил мне серверный модуль Apache, была совершенно ужасной по сравнению с тем, что делает svnserve и собственный протокол Subversion.
Обратите внимание, что у меня есть с тех пор установил отдельный сервер Apache, перебрал множество файлов конфигурации и настроил Subversion с Apache, отличным от сервера VisualSVN, просто чтобы убедиться, что это не просто VisualSVN, и я подтвердил, что наблюдаемая мной скорость не работа команды VisualSVN. Кажется, что протокол HTTP или модули Apache не так быстры.
Мой совет - по возможности использовать основной сервер svnserve. Может потребоваться некоторая работа, чтобы узнать файлы конфигурации для авторизации и т.п., но только фактор раздражения (т.е.
Мы поставляем наши репозитории SVN, используя HTTP, предоставляемый Apache, работающим под CentOS 5.3, изнутри виртуальной машины XEN.
Я бы заметил, что при фиксации или извлечении из большого файла, передает этот файл со скоростью, близкой к сетевой. При проверке или фиксации большого количества небольших файлов накладные расходы на HTTP-запросы намного более заметны.
По сравнению с временными рамками компиляции кода, SubVersion не рассматривается как узкое место внутри компании.
(Это так. мой опыт работы с командой из 10 разработчиков)
I'm using CollabNet at home and at work. It's been fine - no complaints with performance.
Повторный доступ скорость: я видел сервер Apache https: SVN, требующий обновления оборудования. Я, кажется, помню, что главным образом из-за нехватки памяти замедлялись многочисленные процессы Apache, которые конкурировали за ресурсы машины. Но это были 20 разработчиков, которые вместе работали над проектом с извлеченным деревом размером 20 ГБ (там много двоичных файлов, которые часто меняются). И обновление до средне оснащенного сервера решило проблему.
Кроме того, в том же проекте мне пришлось узнать, что SVN на ext3 FS под Linux был как минимум на порядок быстрее, чем на NTFS под Windows. Отметьте это: Linux на виртуальной машине, работающей под управлением Windows, потребовалось в десятой части времени для обновления, конкурирующего с Windows, на которой работала виртуальная машина . (Мы всегда хотели попробовать этот драйвер OS ext3 для Windows и посмотреть, не сделает ли это SVN более быстрым в Windows, чем его родная FS. Однако я покинул проект, прежде чем мы когда-либо пытались.)
В любом случае, это так. не то, что вы решили бросить в камень на вечность. Вы можете попробовать что-то одно, тщательно протестировать в реальном проекте, а позже переключиться на другой сервер и протокол. (Есть даже команда SVN для переключения URL-адреса проверенного дерева . Ее можно использовать для переключения протокола без необходимости проверять все заново.)
Вот что я бы подумал, чтобы решить, протокол: Если у вас есть работающая инфраструктура AD или LDAP, которую вы хотели бы использовать для входа в SVN, попробуйте один из вариантов протокола http / https: . Если у вас его нет, и он вам не понадобится, и вы можете войти в систему собственными средствами SVN, почему бы не использовать скорость, обеспечиваемую протоколом svn: ?
Я никогда не видел репозитория SVN, к которому люди использовали бы доступ WebDAV. IME, они всегда хотят иметь историю при доступе к сети (WebDAV не предоставляет этого, AFAIK), поэтому они использовали один из веб-интерфейсов для SVN. Я никогда не проверял, но предполагаю, что такие вещи, как ViewVC и тому подобное, не заботятся о том, какой протокол они используют для доступа к репо.
Что касается того, какой дистрибутив вы хотите использовать - я думаю, это в основном зависит от личных предпочтений, так как код внизу в любом случае тот же. Я предпочитаю загрузки, для которых мне не нужно регистрироваться, и дистрибутивы, которые явно нацелены на платформу, на которой я хочу их установить. Но это, наверное, только я.
Тем не менее, есть один неоспоримый факт, который вы, возможно, захотите принять во внимание, если ваш репозиторий доступен из Интернета: когда проект SVN выпускал новую версию dot, как долго он в прошлом использовал различные дистрибутивы, чтобы наверстать упущенное. Так как это могут быть исправления безопасности, вы можете предпочесть те, которые обычно предоставляют исправления быстрее.
Есть один неоспоримый факт, который вы, возможно, захотите принять во внимание, если ваш репозиторий доступен из Интернета: когда проект SVN выпустил новую версию dot, как долго в прошлом он использовал различные дистрибутивы, чтобы наверстать упущенное. Так как это могут быть исправления безопасности, вы можете предпочесть те, которые обычно предоставляют исправления быстрее. Есть один неоспоримый факт, который вы, возможно, захотите принять во внимание, если ваш репозиторий доступен из Интернета: когда проект SVN выпустил новую версию dot, как долго в прошлом он использовал различные дистрибутивы, чтобы наверстать упущенное. Так как это могут быть исправления безопасности, вы можете предпочесть те, которые обычно предоставляют исправления быстрее.