Git vs SVN

[katit]

Да, я не в тренде, обьясните что я не прав.. У нас SVN. Но все новые тулы используют Гит по умолчанию, SVN всегда надо отдельно прикручивать и вот я задумался... Зачем и почему оно мне надо? Я понимаю что там типа распределенный девелопмент и т.д. Но нам этого ничего не надо, SVN работает отлично для наших целей. Мы даже редко друг другу "на ноги наступаем"

Хотелось бы услышать историю типа "Перешли и нравится то-то и то-тo". Или "Перешли - та же хрень вид сбоку".

P.S. Один фиг исходники в GitHub мы хранить не будем и надо свой сервер будет ставить.

[Prosche]

В вашем случае я бы остался на СВН.

[geek7]

перешли и на кактусах git оставленны многочисленные обрывки одежды, все задницы исцарапаны... но мужественно продолжаем лезть на те-же кактусы. Ибо Тренд, аминь

[Boriskin]

На новом месте работы используется только Гит, до этого 10+ лет пользовался Сабом (на работе и дома). Мысли такие - git лучче интегрируется с CI и прочими приблудами, которые триггерятся через PR, но модель сильно отличается от Сабвершина и приходится частично переучиваться. Основное преимущество гита - намного меньшие шансы сломать билд, тк если PR не проходит тесты - то он просто не засасывается, это удобно при большом кол-ве работников или при наличии критичной массы идиотов.
Если разрабы отличные и процесс отлажен - то Саб вполне достаточен и отлично работает, и смысла переходить - нет.

[StrangerR]

У нас меркуриал и SVN, в паре проектов ГИТ, у меня часть скриптов вообще в CVS живут.

ГИТ и Меркуриал придуманы для слабо связной разработки, SVN для разработки которая ведется централлизованно.

[iDesperado]

имхо svn vs git это как паровоз vs современное авто. даже если задача скататься из пункта А в Б, все равно авто удобней и больше гибкости. лопатой махать не нужно и маршрут интересней проложить можно. в svn помню в бранчи файлы физически копируют, если проект большой тупо время отнимало. десяток бранчей это проект x10. в гите же все много проще, даже если ты один. надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда.

[Uzito]

git мне сломал разум. master vs origin.. what's the fucking difference?
Вызов всех команд руками из командной строки. TortoiseGit по удобству использования отстает на десять лет от TortoiseSVN.
Почему коммит делается только локально и не выносится в главный репозиторий?
Вася работает над файлом Zhopa.java, я работаю над файлом hernya.SQL. Если Вася зачекинит свою жопу в репозиторий, почему я не могу зачекинить свою херню без предварительной синхронизации Васиной жопы в мою локальную копию?

[uncle_Pasha]

Отпустил бы в свое время IBM ClearCase в opensource вместо того, чтоб угробить, было бы хоть что-либо приличное для централизованной и не только разработки...
По сути вопроса - закапывайте SVN, ставьте Git.

[katit]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда

Т.е. преимущество в бренчах? Мы ими не пользуемся. Если надо чего-то проверить то есть другие способы. Или "проверка" длится днями/неделями?

По сути вопроса - закапывайте SVN, ставьте Git.

Голос за Git но без обьяснений почему.

[Alexander Troyansky]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда

Т.е. преимущество в бренчах? Мы ими не пользуемся...

так это ж то (одно из) из-за чего git и svn используются. Просто в SVN бранчи реализованны немного иначе

[katit]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда

Т.е. преимущество в бренчах? Мы ими не пользуемся...

так это ж то (одно из) из-за чего git и svn используются. Просто в SVN бранчи реализованны немного иначе

Я понимаю, но мы их не используем, представляете? Все идет в продакшн...

[Alexander Troyansky]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда

Т.е. преимущество в бренчах? Мы ими не пользуемся. Если надо чего-то проверить то есть другие способы. Или "проверка" длится днями/неделями?

По сути вопроса - закапывайте SVN, ставьте Git.

Голос за Git но без обьяснений почему.

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

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

[Alexander Troyansky]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

надо проверить - сделал бранч 2 секунды, не взлетело - грохнул бранч 1 секунда

Т.е. преимущество в бренчах? Мы ими не пользуемся...

так это ж то (одно из) из-за чего git и svn используются. Просто в SVN бранчи реализованны немного иначе

Я понимаю, но мы их не используем, представляете? Все идет в продакшн...

Это - классика

[Uzito]

Итого результат интересен. Большинство сказали что в принципе нафиг не надо Git.

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

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

С другой стороны работаю вот сейчас с другим проектом, который использует Amazon Code Commit и облачные технологи. Пять девелоперов, никаких бранчей нет вообще, но у амазона только Git.

[KVA]

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

[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 например)