Git vs SVN

[Alexander Troyansky]

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

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

[iDesperado]

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

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

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

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

А давайте до кучи здесь еще и про TFS поговорим. У нас например SVN и предлагают на TFS переползти но не особо настойчиво.

У нас был Perforce. Потом переползли на TFS.
Сначала было немного непривычно, но втянулись.

TFS имеет встроенный git.

[geek7]

про то как гит работает с бинарниками (большими) уже поговорили?

Нет, как?

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

[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 лет исполнится в следующем году.

[kostik78]

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

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

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

Вы о чем господа ?

https://subversion.apache.org/docs/rele ... story.html
Subversion 0.37 (1.0.0-RC1) (25 Jan 2004): First release candidate for Subversion-1.0.0.

Subversion 0.14.2 (22 August 2002): Interim release; see issues marked with the "0.14.2" milestone.
Milestone 1 (20 October 2000): Basic working copy manipulation; client can checkout/update/commit using XML files.

[kostik78]

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

А Вы вкурсе что версия 1.0 не значит первый юзабельный релиз. Многие успешные продукты долго жили в версиях < 1

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

Не знаю. Я пользоваться гитом начал с тех пор как начал ковырялся в linux kernel. Подобных "ужасов" не помню.

[KVA]

Мы на TFS сидим - основное преимущество это наличие source control, work item tracking, test case management & build/deployment в одном флаконе без плясок с бубном для интеграции всего этого вместе из кусочков.

Вот и я о то том же. Меня просто поразило когда в моей старой конторе взяли вот это все налаженное, сломали и вместо этого начали лепить Git, Jira, TeamCity и прочая прочая с упрором на Lunux way. При том что контора на 90% Windows.

[Alexander Troyansky]

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

А Вы вкурсе что версия 1.0 не значит первый юзабельный релиз. Многие успешные продукты долго жили в версиях < 1

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

Не знаю. Я пользоваться гитом начал с тех пор как начал ковырялся в linux kernel. Подобных "ужасов" не помню.

Что со мной происходит... за два дня уже два раза подтасовал факты... Пришлось посмотреть записи (2011-й год). Ахтунг! Действительно, не было у гита проблем со скоростью (лично задокументировал при исследовании). Были проблемы у Меркуриала:

bash-3.00$ time hg update
0 files updated, 0 files merged, 0 files removed, 0 files unresolved

real 53m1.927s
user 19m8.274s
sys 4m13.723s


Subversion is more flexible and faster when it comes to updating particular folders, w/o involving the whole tree:

bash-3.00$ time svn up
At revision 9812.

real 0m0.646s
user 0m0.071s
sys 0m0.041s

Гит выкидывал песдецы похлеще, например, такие:

Counting objects: 98390, done.
Delta compression using up to 16 threads.
Compressing objects: 100% (90882/90882), done.
Writing objects: 100% (98390/98390), 1.09 GiB | 4.86 MiB/s, done.
Total 98390 (delta 40708), reused 0 (delta 0)
error: unable to write sha1 filename ./objects/pack/pack-73431a27625c28ea81523c3bec4ac80fdf146723.pa

fatal: failed to write object
fatal: unpack-objects failed

Братья по разуму в тырнете посоветовали...

$ git-prune
$ git-gc --aggressive
$ git-repack
$ git-repack -a
$ git-prune-packed

areyoufuckingserious? Ну ок... я немножко поплясал ещё с этим делом с различными магическими гитовскими заклинаниями, мне тогда не помогло. Ну и нах, так и остался со свином. Вчера пробовал - гит всосал, не подавившись. Ура справедливость восстановлена, но осадочек остался с тех пор.

[katit]

Мы на TFS сидим - основное преимущество это наличие source control, work item tracking, test case management & build/deployment в одном флаконе без плясок с бубном для интеграции всего этого вместе из кусочков.

Вот и я о то том же. Меня просто поразило когда в моей старой конторе взяли вот это все налаженное, сломали и вместо этого начали лепить Git, Jira, TeamCity и прочая прочая с упрором на Lunux way. При том что контора на 90% Windows.

TFS денег стоит, а так да, почему нет