5 причин для обновления до Subversion 1.7

Apache Software Foundation объявила о выпуске Subversion 1.7, но какие именно из новых возможностей 1.7 полезны пользователю? А почему бы вам не обновиться до версии 1.7? Под катом пять причин перехода на Subversion 1.7.

1) Полностью переписана рабочая система копирования метаданных

В Subversion 1.7 система копирования метаданных была полностью переписана. Для пользователя это означает непосредственное увеличение производительности. Все метаданные для рабочей копии теперь хранятся в одном хранилище в корне, так Subversion больше не придется ходить по всему дереву каталогов, чтобы собрать все необходимые сведения о рабочей копии.
2) Улучшен HTTP протокол

В 1.7 команда Subversion решила отказаться от DeltaV в пользу нового HTTP-протокола «HTTPv2». Это имеет ряд преимуществ для пользователя:
  • Уменьшение накладных расходов, связанных с DeltaV (например, дополнительный порт в Apache для записи логов)
  • Уменьшение клиент-серверных циклов обработки каждого запроса повышает производительность.
  • Уменьшение нагрузки на сервер (за счет меньшего количества запросов к логам и уменьшения обращений к хранилищам.)

3) Получение контроля над кэшем

В версии 1.6 введена система кэширования в памяти, но многие пользователи испытывали проблемы с увеличением количества выделяемой памяти под кэш. Subversion 1,7 дает вам больший контроль над кэшем:
  • Управление памятью используемой кэшем, чтобы предотвратить большие объемы памяти, используемые кэшем.
  • Новая структура кэширования и новый код, который имеет более лучшие показатели в отношении использования памяти.

4) Настраиваемая степень сжатия

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

5) Новая функция удалённого дампа ‘svnrdump’

Subversion 1.7 дает пользователям возможность копировать дамп на удаленные репозитории. Не требуется админский доступ к хранилищам!
+17
17 октября 2011, 23:59
8
BusteR27 6,5

комментарии (32)

+2
gvsmirnov #
Переименуйте топик в «5 причин для обновления на Subversion 1.7», а то можно подумать, что вы с нормальной системы контроля версий рекомендуете перейти на svn.
–2
ha2bj #
50 причин для обновления Subversion v1.7 до Git v1.7.7
+3
BusteR27 #
Можно и Яндексу порекомендовать перейти с свн на гит
+1
zerkms #
Яндекс, стало быть, пользуется СВНом не потому, что на него завязано слишком много из инфраструктуру и по историческим причинам, а именно потому, что свн объективно лучше.

Нуну.
+1
asolntsev #
Мы на работе используем и GIT, и SVN в зависимости от проекта.
И большинство склоняется к тому, что SVN предпочтительнее.

Детали я собрал здесь: asolntsev.livejournal.com/53660.html
+15
HoochieMen #
Вот любят же тту свой троллинг кругом показывать. Почему не написать «что вы с ДРУГОЙ системы контроля версий рекомендуете перейти на svn.», нет вот обязательно нужно указать свое мнение по поводу «ненормальности» svn
–1
limitium #
Ой ли? в данный момент приходится пользоваться svn, git, mercurial и почему-то проблемы только с svn…
+3
HoochieMen #
а мне приходится использовать svn, git и проблемы нет ни с чем :/
+2
kekekeks #
Будьте готовы к будущему! Оригинальные WC библиотеки стали настолько сложными, что введение новых функций становится все более сложным процессов.
Когда ПРОМТом переводите, вычитывайте хотя бы…
+1
gvsmirnov #
И да: перевод промтом? Половина предложений не согласована либо просто ужасно звучит на русском.

Будьте готовы к будущему! Оригинальные WC библиотеки стали настолько сложными, что введение новых функций становится все более сложным процессов.

Лолшто? Я один ничего не понял?
0
gvsmirnov #
О, не один :)
+3
ddv #
99% процентов(а я наблюдаю все 100% ежедневно) народу юзает svn up и svn commit, а остальное так для интереса попробовали и забыли… в таком случае эти 5 причин очень убедительны…

простота, гибкость, динамика — вот чего мы ждём…

вообще жду когда появится возможность в реальном времени разрешать конфликты, начал набирать в строчке, а СКВ сказала «Лена тут впрогала это», есть повод с Леной пообщаться а не поругаться :-)
+3
tangro #
Ну во-первых, не только «svn up и svn commit». Как минимум без checkout, diff и show log с svn-ом делать нечего.
Во-вторых, ускорение работы благодаря новому протоколу или кешу поможет даже если пользоваться только этим.
0
bstan #
У меня пока что неудачный опыт общения с новой версией. На текущий момент операции Commit и Update стали проходить заметно дольше… Списываю это на то, что база теперь общая, и соответственно большая по объему.
Мое хранилище имеет глубокую древовидную структуру (глубина вложения 5 и более папок), и тут я заметил только снижение производительности, при работе с новой версией… 1.6 отрабатывала заметно быстрее
0
andrewsch #
+3
shifty #
А как на счет совместимости старых/новых версий репозиториев?
0
netslow #
Меня тоже волнует вопрос совместимости! Если у меня проект в Eclipse'е привязан к svn, я его закоммичу с помощью Tortoise, в Eclipse он потом будет работать?
0
andrewsch #
Больной пока вопрос :-) Для Eclipse вроде можно установить dev-версию subclipse-a (я не пробовал), но стабильные версии IDE и их плагинов пока официально не поддерживают 1.7. Idea обещает в 11-ой версии.
0
andrewsch #
У меня наоборот — против 2-4 минут обновления клиентом 1.6 теперь с клиентом 1.7 обновление занимает 10-20 секунд. Это при неизменном сервере 1.6 (HTTP).
0
andrewsch #
Это было в ответ на комментарий тов. bstan
0
bstan #
Ну в моем случае версия сервера 1.4 :) Но у меня проблема не с передачей данных на сервер и обратно, а пре- и пост- обработка данных при синхронизации

Соглашусь — непосредственно передача и получение данных — быстрее стало
–3
fsgs #
Теперь на 64-битную Win7 не ставится 32-битная версия TortoiseSVN. А я использую Total Commander и у него по умолчанию 32-битное контекстное меню. Зачем они так сделали? Как теперь предлагается использовать меню TortoiseSVN из Total Commander?
+3
KindDragon #
Теперь 64-битный установщик TortoiseSVN включает и 32-битную версию, как у всех нормальных программ. Просто установите 64-битный TortoiseSVN.
0
Scrup #
У Тотала есть приблуда (по-моему, даже в базовом дистрибутиве) — TCMDX64.EXE. Она добавляет в контекстное меню Винды, вызываемое из-под Тотала, подменю X64.
+1
aaacmc #
1 причина для того, чтобы не спешить с переходом — падает оно…
0
Funbit #
Win7 64 + Tortoise SVN + (VS2010 + VisualSVN), полёт нормальный с момента релиза. Обновил десятки проектов, пользуюсь практический целый день, пока ни одного глюка.
0
xdemon #
Когда его можно будет без апача использовать? :/
0
Paul #
В качестве сервера? Можно использовать по протоколам svn:// svn+ssh:// и file://. Клиент как бы и так не требует никакого апача.
0
xdemon #
svn+ssh — под шиндоус вряд ли заведется. File:// — нужен локальный реп либо маунт, опять же под шиндоус только костыли

svn:// всем хорош, да только где там крипто (ssl)? Я думал через stunnel сделать, но пока руки не дошли.
+1
Paul #
Есть мануалы по поднятию ssh сервера на винде, как Cygwinовского так и OpenSSH. Ну еще можно поднять VPN и юзать просто svn://.

У апача бонус в том, что он может использовать LDAP авторизацию, это удобно, если виндовые машины в домене. Ну и поднять его на винде совсем несложно.
–3
avz #
Причина номер 1 вашем списке — это та единственная, которой было достаточно, чтобы я откатился до 1.6 — мне это неудобно.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.