|
svn vs git, что лучше? |
|
|
|
Oct 8 2010, 04:04
|

Профессионал
    
Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072

|
Интересно, что такое большой репозиторий ? Посмотрите на этот: http://svn.freebsd.org/base/. Размер около 10ГБ, файлов - не счесть, ревизий более 200 тысяч. И ничего, работает вполне нормально. Поэтому проблема скорее всего в чем-то другом. На счет того, что выбрать. Как уже сказал neiver, это две разные модели хранения веток разработки. В случае svn, если вам нужно надолго отпочковаться от базовой ветки вы просто создаете еще одну ветку и делаете в ней что хотите, при этом можно дать другим посмотреть на плоды вашего творчества. При этом все хранится на одном сервере, упрощается администрирование и бэкапы. В случае с git, репозиторий можно клонировать и работать с ним на локальной машине, но за хранение и доступ уже отвечаете вы сами. Вся остальная функциональность схожа, за исключением мелких отличий в силу разных идеологий. Касательно версий: всегда использовали только официальные ветки/билды и не было никаких проблем. Естественно, для всех операций использовали только rapid-svn, командную строку или ее обертки из оболочек/редакторов.
|
|
|
|
|
Oct 8 2010, 05:12
|

Гуру
     
Группа: Свой
Сообщений: 2 429
Регистрация: 30-11-05
Из: Ижевск
Пользователь №: 11 606

|
Цитата Svn - централизованная, Git - распределённая В этом я вижу пока только минусы git. Мы выдем проект вдвоем. В случае с svn если возникают проблемы с компиляцией можно сделать update на предыдущую ревизию из репозитория и продолжать работать. А с git если я и коллега что-то попортим в своих исходниках то делать update неоткуда. Или git хранит историю изменений на каждой локальной копии и update делается со своего же компа? Цитата Интересно, что такое большой репозиторий ? Посмотрите на этот: http://svn.freebsd.org/base/. Размер около 10ГБ, файлов - не счесть, ревизий более 200 тысяч. И ничего, работает вполне нормально. У нас исходники весят около 1,5ГБ файлов около 60000. Значит svn с этим должен легко работать. Цитата Поэтому проблема скорее всего в чем-то другом. Похоже в eclipse+subclipse. Вчера для пробы сделал checkout из консоли в другой каталог, завершилась менее чем за час. На checkout из subclipse уже потрачено часов 5 и еще не завершено. Похоже стоит использовать rapid-svn, а в eclipse только редактировать код.
|
|
|
|
|
Oct 8 2010, 09:47
|
Местный
  
Группа: Участник
Сообщений: 214
Регистрация: 22-03-10
Из: Саратов
Пользователь №: 56 123

|
Да, именно так. Гит обычно хранит всю историю изменений в каждой копии препозитория. Но можно и сделать checkout только последней ревизи если надо. Причем все репозитории и рабочие копии главный рапозиторий(если такой имеется) впринципе равнозначны. Цитата . Вчера для пробы сделал checkout из консоли в другой каталог, завершилась менее чем за час. Это по локальной сети? Или через инернет канал мегабита в четыре? У меня ~ 1 GB исходников. На работе по 100 мегабитной локальной сети репозиторий клонируется меньше чем за 10 мин. Из дома 4Mbit минут за 40. Вся служебная информация(читай история изменений) занимает 170 Мб при 1Гб исходников и полутора годовой истории изменений.
|
|
|
|
|
Oct 8 2010, 11:26
|
Профессионал
    
Группа: Свой
Сообщений: 1 975
Регистрация: 30-12-04
Из: Воронеж
Пользователь №: 1 757

|
Цитата(uriy @ Oct 8 2010, 09:12)  В этом я вижу пока только минусы git. Нету никаких минусов. Более того, на мой взгляд, у централизованных VCS нет никаких преимуществ перед децентрализованными. Имея копию репо у себя, вы не зависите от наличия соединения с севером. Например, захотелось вам сделать svn log или svn blame, а сервер c репо недоступен. Вот и аюшки. Цитата Мы выдем проект вдвоем. В случае с svn если возникают проблемы с компиляцией можно сделать update на предыдущую ревизию из репозитория и продолжать работать. А с git если я и коллега что-то попортим в своих исходниках то делать update неоткуда. С git можно работать так же, как и с svn: сделать центральный репо, с которым периодически синхронизироваться (git pull/git push). Разумеется, любое изменение можно откатить. А за git bisect я бы авторам поставил памятник. Более того, работа с ветками в git гораздо более приятная (включая git rebase и git cherry-pick). git merge вообще сказка. Работа с отдельными коммитами тоже на высоте: git rebase -i позволяет изменить порядок коммитов, слить несколько коммитов в один, убрать ненужные. Итого: имея опыт работы и с git, и c svn, я большого смысла в использованиии svn не вижу.
|
|
|
|
|
Oct 11 2010, 09:32
|
Участник

Группа: Участник
Сообщений: 63
Регистрация: 17-09-09
Пользователь №: 52 434

|
Цитата(:-) @ Oct 9 2010, 12:11)  Извините, что влезаю в дискуссию, но подскажите достойную литературу по svn и по git. Мало что знаю про системы контроля версий, а разобраться хочется... Официальная документация - самая достойная литература
|
|
|
|
|
Oct 11 2010, 12:03
|
Местный
  
Группа: Участник
Сообщений: 214
Регистрация: 22-03-10
Из: Саратов
Пользователь №: 56 123

|
Цитата(halfdoom @ Oct 9 2010, 08:55)  В git мне не нравится структура в виде сотни с лишним разнородных скриптов, предпочитаю более цельные продукты. Its a UNIX way. А чем она эта структура не нравится? Все эти "скрипты" доступны из одной команды "git": git init git pull git push git rebase ... А если хочется вида целостного продукта, то можно и графическую морду к нему поставить. Я вот GitExtensions пользуюсь. Удобная штука, рекомендую.
|
|
|
|
|
Oct 11 2010, 13:21
|

Профессионал
    
Группа: Свой
Сообщений: 1 003
Регистрация: 20-01-05
Пользователь №: 2 072

|
Цитата(neiver @ Oct 11 2010, 16:03)  А чем она эта структура не нравится? Все эти "скрипты" доступны из одной команды "git": Выбор VCS очень ответственная задача, т.к. сбои в ее работе могут обернуться серьезными последствиями и простоями. Поэтому мне важно качество кода. Посмотрите на количество релизов git - более 160 за 5 лет, для subversion эта цифра в два раза меньше, но за 7 лет. Ну, и то, что git таскает за собой весь репозиторий для меня является недостатком, т.к. нет возможности извлечь файлы/историю только для подпроекта. Насколько я знаю, это до сих пор не решено в полной мере, т.к. изначально git разрабатывался для монолитных проектов типа ядра Linux.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|