Comments 32
50 причин для обновления Subversion v1.7 до Git v1.7.7
Можно и Яндексу порекомендовать перейти с свн на гит
Яндекс, стало быть, пользуется СВНом не потому, что на него завязано слишком много из инфраструктуру и по историческим причинам, а именно потому, что свн объективно лучше.
Нуну.
Нуну.
Мы на работе используем и GIT, и SVN в зависимости от проекта.
И большинство склоняется к тому, что SVN предпочтительнее.
Детали я собрал здесь: asolntsev.livejournal.com/53660.html
И большинство склоняется к тому, что SVN предпочтительнее.
Детали я собрал здесь: asolntsev.livejournal.com/53660.html
Вот любят же тту свой троллинг кругом показывать. Почему не написать «что вы с ДРУГОЙ системы контроля версий рекомендуете перейти на svn.», нет вот обязательно нужно указать свое мнение по поводу «ненормальности» svn
Будьте готовы к будущему! Оригинальные WC библиотеки стали настолько сложными, что введение новых функций становится все более сложным процессов.Когда ПРОМТом переводите, вычитывайте хотя бы…
99% процентов(а я наблюдаю все 100% ежедневно) народу юзает svn up и svn commit, а остальное так для интереса попробовали и забыли… в таком случае эти 5 причин очень убедительны…
простота, гибкость, динамика — вот чего мы ждём…
вообще жду когда появится возможность в реальном времени разрешать конфликты, начал набирать в строчке, а СКВ сказала «Лена тут впрогала это», есть повод с Леной пообщаться а не поругаться :-)
простота, гибкость, динамика — вот чего мы ждём…
вообще жду когда появится возможность в реальном времени разрешать конфликты, начал набирать в строчке, а СКВ сказала «Лена тут впрогала это», есть повод с Леной пообщаться а не поругаться :-)
У меня пока что неудачный опыт общения с новой версией. На текущий момент операции Commit и Update стали проходить заметно дольше… Списываю это на то, что база теперь общая, и соответственно большая по объему.
Мое хранилище имеет глубокую древовидную структуру (глубина вложения 5 и более папок), и тут я заметил только снижение производительности, при работе с новой версией… 1.6 отрабатывала заметно быстрее
Мое хранилище имеет глубокую древовидную структуру (глубина вложения 5 и более папок), и тут я заметил только снижение производительности, при работе с новой версией… 1.6 отрабатывала заметно быстрее
А как на счет совместимости старых/новых версий репозиториев?
У меня наоборот — против 2-4 минут обновления клиентом 1.6 теперь с клиентом 1.7 обновление занимает 10-20 секунд. Это при неизменном сервере 1.6 (HTTP).
Это было в ответ на комментарий тов. bstan
Ну в моем случае версия сервера 1.4 :) Но у меня проблема не с передачей данных на сервер и обратно, а пре- и пост- обработка данных при синхронизации
Соглашусь — непосредственно передача и получение данных — быстрее стало
Соглашусь — непосредственно передача и получение данных — быстрее стало
Теперь на 64-битную Win7 не ставится 32-битная версия TortoiseSVN. А я использую Total Commander и у него по умолчанию 32-битное контекстное меню. Зачем они так сделали? Как теперь предлагается использовать меню TortoiseSVN из Total Commander?
Теперь 64-битный установщик TortoiseSVN включает и 32-битную версию, как у всех нормальных программ. Просто установите 64-битный TortoiseSVN.
У Тотала есть приблуда (по-моему, даже в базовом дистрибутиве) — TCMDX64.EXE. Она добавляет в контекстное меню Винды, вызываемое из-под Тотала, подменю X64.
Вот вот Total скоро тоже станет 64 битным, 8-ая версия грядёт.
1 причина для того, чтобы не спешить с переходом — падает оно…
Когда его можно будет без апача использовать? :/
В качестве сервера? Можно использовать по протоколам svn:// svn+ssh:// и file://. Клиент как бы и так не требует никакого апача.
Причина номер 1 вашем списке — это та единственная, которой было достаточно, чтобы я откатился до 1.6 — мне это неудобно.
Sign up to leave a comment.
5 причин для обновления до Subversion 1.7