Git vs SVN

[katit]

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

Все, понял. Мы делаем 1 и 2 регулярно. И 3 это не про нас.

[iDesperado]

SVN, с моей точки зрения, имеет несколько преимуществ при работе с очень большими репами. Если надо вытащить только один кусочек огромной репы, то в SVN это делается командой checkout с указанием этого кусочка.

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

[Alexander Troyansky]

SVN, с моей точки зрения, имеет несколько преимуществ при работе с очень большими репами. Если надо вытащить только один кусочек огромной репы, то в SVN это делается командой checkout с указанием этого кусочка.

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

Уаще нихера не понял... Например, у меня есть громадная репа тестов. Из которой мне нужно в данный момент поработать с ограниченным наборов тестов, а то и вообще только одним. Я вытаскиваю этот только этот тест (каталог). В git, надо или разбивать эту репу либо над независимые (с потерей возможности копирования-переноса между этими независимыми репами), либо делать checkout всей огромной репы. О том, что инструмент не потянет: в своё время исследовал возможность использования Git и Mercurial и пытался залить репу в эти самые новые инструменты, которые "должны были потянуть". Всё заканчивалось несколько печально для инструментов. Признаю, что мог делать что-то неправильно и что с тех пор эти инструменты заматерили, но больше попыток не повторял.

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

Подозреваю, что люди, когда работают с кодом линукса, либо работают с несколькими мелкими репами, либо каждый раз указывают какие файлы (первый шаг: git add <staged files>) надо добавить в коммит (второй шаг: git commit) и не используют commit -a

[iDesperado]

В git, надо или разбивать эту репу либо над независимые (с потерей возможности копирования-переноса между этими независимыми репами), либо делать checkout всей огромной репы. О том, что инструмент не потянет: в своё время исследовал возможность использования Git и Mercurial и пытался залить репу в эти самые новые инструменты, которые "должны были потянуть". Всё заканчивалось несколько печально для инструментов. Признаю, что мог делать что-то неправильно и что с тех пор эти инструменты заматерили, но больше попыток не повторял.

вы сталкиваетесь с проблемами какие не знакомы крупнейшим проектам этой планеты. причем на той самой планете, где крупные проекты именно с свн переехали на гит. вывод напрашивается сам собой.
svn переехал в разряд легаси и в первую очередь потому, что любое серьезное сравнение начинается "Git is much faster than Subversion" (с) https://git.wiki.kernel.org/index.php/GitSvnComparsion
навороты с бранчами, чери пик комита из одного в другой, это действительно не всем нужно, а вот скорость киллер фича.

[Мальчик-Одуванчик]

SVN работает отлично для наших целей. Мы даже редко друг другу "на ноги наступаем"

Вот и у нас аналогично. Все-таки это довольно второстепенный инструмент чтобы без особой причины заморачиваться его улучшением.

[Alexander Troyansky]

В git, надо или разбивать эту репу либо над независимые (с потерей возможности копирования-переноса между этими независимыми репами), либо делать checkout всей огромной репы. О том, что инструмент не потянет: в своё время исследовал возможность использования Git и Mercurial и пытался залить репу в эти самые новые инструменты, которые "должны были потянуть". Всё заканчивалось несколько печально для инструментов. Признаю, что мог делать что-то неправильно и что с тех пор эти инструменты заматерили, но больше попыток не повторял.

вы сталкиваетесь с проблемами какие не знакомы крупнейшим проектам этой планеты...

Не сталкиваюсь, а сталкивался (прошедшее время):

...в своё время исследовал возможность использования...

Сейчас для интереса попробовал. Действительно Git сильно улучшился. Когда я несколько лет назад проводил тест (1.7.2, кажется), операция commit даже в листовом каталоге работала более 50 мин вследствие размера репы, как мне объяснили в то время. Такая же операция в произвольном месте месты уже значительно возросшей репы занимает несколько секунд. Правда сейчас у меня в системе - SSD, а раньше - HDD. Так что своё заявление, что для быстрой работы Git надо разбивать на части, признаю неверным в нынешних условиях.

[uncle_Pasha]

а вот скорость киллер фича.

"лучше день потерять, потом за пять минут долететь" (с

phpBB [video]

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

[geek7]

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

Подозреваю, что люди, когда работают с кодом линукса, либо работают с несколькими мелкими репами, либо каждый раз указывают какие файлы (первый шаг: git add <staged files>) надо добавить в коммит (второй шаг: git commit) и не используют commit -a

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

[katit]

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

Нет, как?

[kostik78]

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

Подозреваю, что люди, когда работают с кодом линукса, либо работают с несколькими мелкими репами, либо каждый раз указывают какие файлы (первый шаг: git add <staged files>) надо добавить в коммит (второй шаг: git commit) и не используют commit -a

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

А что у SVN нет тех же проблем что и у гита при подсчете чек суммы и просчете дельты ? На сколько я знаю что у svn что и у git в данном месте алгоритм работы схож, так что "болеют" они от больших файлов одинаково. Только вот в svn построить нормальный девелопмент процесс с использованием бранчей не возможно.
Кстати, последние версии гита уже "умные" и не пытаются делать diff на binaries а обрабатывают их как целый файл (что делает perforce например)

[Alexander Troyansky]

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

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

[iDesperado]

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

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

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

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

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

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

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

[geek7]

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

Нет, как?

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