Git vs SVN

[uncle_Pasha]

насколько я знаю, гит не заморачивается сохранением именно дельты от файла . как следствие размер рипо растёт некислыми темпами

Что такое дельта бинарного файла? Например, jpeg/mpeg?
С бинарниками, любое репо начнети расти нехилыми темпами. Другое дело, что в случае централизованного репозитория их качают только те, кому это надо, а в случае Git-а и иже с ними - все.

[Alexander Troyansky]

А что у SVN нет тех же проблем что и у гита при подсчете чек суммы и просчете дельты ?

Из SVN репы мона вытащить тока один такой bin-файл отдельно. Git заставляет тянуть всю репу, или уже тоже пофиксили?

в гите можно вытягивать часть репы через sparse-checkout

Даже не sparse-checkout (чтобы всю репу не тянуть), а что-то типа sparse-clone есть? и так что-бы не пляски 5-6 командами, а просто одной?

[Alexander Troyansky]

Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.

В svn уже и ветки низя создавать?

[Palych]

Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.

А можно попросить пояснить почему?

[Palych]

Мы тоже с SVN на git переползать собираемся.
Мне пока главным преимуществом git видится rebate, но страшно даже подумать сколько будет геморроя...

[Вячеслав Викторович]

Мы тоже с SVN на git переползать собираемся.
Мне пока главным преимуществом git видится rebate, но страшно даже подумать сколько будет геморроя...

самый прикол, что checkout и revert означает совсем другое.

[kostik78]

Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.

В svn уже и ветки низя создавать?

Можно, но сложность рипитабл мержа между бранчами сводит полезность иных близко к 0. По этой причине они не "съедобны". Таже проблема у p4, хотя чуток лучше.

[StrangerR]

SVN, с моей точки зрения, имеет несколько преимуществ при работе с очень большими репами. Если надо вытащить только один кусочек огромной репы, то в SVN это делается командой checkout с указанием этого кусочка. В git без выкачивания всей репы этого не сделать. Более того, делать операцию commit в SVN в каталогах низкого уровня - дело нескольких секунд. Git, в силу архитектурных особенностей, шарится в поисках изменений по всему дереву репы, что для очень больших реп выливается во многие минуты ожидания.

Ежели работа идёт с мелкими репами, то git будет лучше. Возможность делать локальные коммиты, лучше встроенный дифф, и много чего остального.

Это кстати причина того, почему наши скриптовые дела, которые живут частично аж в CVS, не перетаскиваются в HG или GIT - потому что вечно вытаскивается поддиректория проекта. И на фига мне гит/hg идея что ко мне сначала приезжает весь проект а потом уже из него я могу и кусочки таскать?

реально, все зависит от связности проекта и от количества бранчей и девелоперов. Для сильно связанного проекта SVS будет пожалуй удобнее. Для опен соурс проектов он вообще не подходит (и именно
для них и был создан git, чтобы два хакера могли ужиться в одной берлоге).

а по конторе статистика (выбор системы зависит от кастомера а они все крупные)

- процентов 80 Mercurial
- процента 2 git но могу и ошибиться.
- процентов 15 SVN
- оставшиется 3 CVS

[kostik78]

Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.

А можно попросить пояснить почему?

Написал выше. Я работал 5 лет на SVN, около 15 лет с Perforce и 8 лет с git. Последний по удобству для девелоперов и релиз инженеров выше двух других на несколько голов. У гита есть одна "проблема" - он позволяет сделать практически все, и очень часто люди не разобравшись в деталях и последствиях той или иной команды/опции получают сайд-эффекты. Для примера: workflow с использованием rebase (не правильным использование) может просто привести к тому что git automatic merge перестанет работать и он в этом плане уподобиться svn or perforce. А automatic merge + fast forward merge + light weight branches это основные бенефиты использования git и почему он гораздо эффективнее в работе.

Далее, тут сказали что git тянет весь репо на локальную машину и это очень плохо. Вообщем наверное это плохо если кто-то работает с один или двумя файлами репозитория. В противном случае это бенефит. И дело не в распределенной команде. Народ часто работает не находясь в офисе. (Я для примера в офисе ничего програмировать не могу, не дают. Постоянно кто-то приходит и дергает, митинги или междусобойчики обсудить то или другое).
Очень удобно работать и делать комиты без необходимости держать VPN поднятым. А потом выложить несколько различных pull/merge requests когда VPN is up or you come to the office. И опять же light weight git branches помогают в этом. Гит помогает отделать "мух от котлет" во время работы.

Ну вообщем много можно дальше продолжать. Мой персональный опыт: git позволяет быть более эффективным чем Perforce и тем более svn.

[Вячеслав Викторович]

Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.

В svn уже и ветки низя создавать?

Можно, но сложность рипитабл мержа между бранчами сводит полезность иных близко к 0. По этой причине они не "съедобны". Таже проблема у p4, хотя чуток лучше.

ну я как бы отвечаю за это обычно, уже несколько лет. сложности есть только у тех кто не умеет, но с git та же самая проблема.

[kostik78]

ну я как бы отвечаю за это обычно, уже несколько лет. сложности есть только у тех кто не умеет, но с git та же самая проблема.

Я не пользовался svn лет 15 уже. Но мой хороший знакомый недавно ушел с него. Согласно ему проблему в корне не решили и мерже в svn все также мрак ... пускай чуть лучше чем раньше было.

[Вячеслав Викторович]

ну я как бы отвечаю за это обычно, уже несколько лет. сложности есть только у тех кто не умеет, но с git та же самая проблема.

Я не пользовался svn лет 15 уже. Но мой хороший знакомый недавно ушел с него. Согласно ему проблему в корне не решили и мерже в svn все также мрак ... пускай чуть лучше чем раньше было.

Ну я как бы тоже перехожу, т.к. заказчики хотят. Но у меня не было особых проблем с svn и с git тоже не будет.

[Alexander Troyansky]

ну я как бы отвечаю за это обычно, уже несколько лет. сложности есть только у тех кто не умеет, но с git та же самая проблема.

Я не пользовался svn лет 15 уже...

Понятно... Initial release date: February 23, 2004...

более ранние версии гита были ещё хуже по съедобности (коммит 50 минут, Карл Константин). Какой смысл ворошить прошлое? Если бы сейчас выбирал, то пользовался однозначно только гитом. Лет 10 назад - у гита были серьёзные на больших репах.

[major Major Major Major]

Мы на TFS сидим - основное преимущество это наличие source control, work item tracking, test case management & build/deployment в одном флаконе без плясок с бубном для интеграции всего этого вместе из кусочков. К примеру, код коммитится, к нему пристыковывается баг готорый был этим кодом пофиксен, реактивируется тест кейс который был сломан, в результате чего был создан баг который был закоммиченым кодом пофиксен. Все это отражается в графиках и отчетах. При этом TFS может в качестве конкретно source control использовать тот же Git. Мы так не делаем, вместо бранчей на каждый чих в родном TFS source control используются shelf sets + сколько угодно workspace, необходимости в git не ощущаю. Ни devopа, ни билд мастера, то есть никакого специально выделенного чела для обслуживания всего этого добра нет, просто не надо. Все работает и так

[Big Cheese]

ну я как бы отвечаю за это обычно, уже несколько лет. сложности есть только у тех кто не умеет, но с git та же самая проблема.

Я не пользовался svn лет 15 уже.

гости из будушшэго детектед! svn 15 лет исполнится в следующем году.