Git против SVN Опции

[Litkevich Yuriy]

Тут можно потрепаться на эту тему.
Хотя впрочем преимущества Git'а для меня, УЖЕ, стали очевидны. Помимо самой, нормальной, идеи веток и меток. Обнаружил ещё одно существенное преимущество Git'а - компактность хранилища.

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

SVN-Зеркало весит = 544 649 КиБ
Его Git-клон весит = 144 680 КиБ
т.е. более чем в 3,5 раза меньше.

[Kagami]

У git'а проблемы с докачкой...

[Litkevich Yuriy]

пока не напарывался.
Однако скорость git svn fetch заметно медленее чем svnsync (обновление зеркала SVN'а), я думаю, это из-за того, что git-svn - это Perl-сценарий, а не бинарь, как svnsync

[Tonal]

У git-а под виндой с русскими названиями файлов полная труба.
Опять же где-то читал, что текст в кодировках utf-16, utf-32 он воспринимает как бинарь...
Но скорость, распределённость и удобство ветвлений всё покрывают!

[Litkevich Yuriy]

У git-а под виндой с русскими названиями файлов полная труба.

у меня есть единственный файл - misc/протокол_Микродат.txt, проблемы ни какой не заметил

[azure]

У git'а проблемы с докачкой...

и в чем же суть проблемы? может, это проблемы сети, что килобайтная дельта не может быть передана без обрывов? Ну и git fsck никто не отменял

[Iron Bug]

пока меня и svn устраивал всегда...
а в чём особое удобство ветвлений в git?
вот у меня, к примеру, есть куча кода. много чего в юникоде. бинарники, естессна, не складываю в контроль. свои исходники и папки на компе никогда по-русски не называю.
но есть задача, к примеру: надо поковырять там, поковырять тут, а потом слить обе версии, если и то и другое получилось. либо одну откатить, а вторую объявить основной.
ещё бывает, что надо найти все изменения с какой-то конкретной даты.
в git'e это удобно сделано?

Сообщение отредактировал Iron Bug - 27.1.2010, 14:26

[Litkevich Yuriy]

в git'e это удобно сделано?

по сравнению с Git'ом в SVN'е это вообще никак не сделано.

на мой нынешний взгляд, SVN у Git' пока выигрывает за счёт интуитивного GUI, Git-gui и Git-tk довольно кривые и неуклюжие

а в чём особое удобство ветвлений в git?

попробую рассказать на примере.
Ветки существуют двух типов:
1) Ветка сопровождения
2) Функциональная ветка
Первая нужна для сопровождения минорных версий программы
Вторая - для эксперементов и т.д.

Теперь рабочий цикл по первому типу веток - Ветка сопровождения:
1) Принимается решение о выпуске новой версии программы, допустим v1.1.0
SVN:
a) trunk копируется в branches с новым именем v1.1.x - это ветка сопровождения;
b ) вновь созданный каталог branches/v1.1.x копируется в tags с именем v1.1.0 - это метка
c) фиксируются изменения в хранилище.
Итого имеем два дубля trunk'а (ну что-то там с экономится сожмётся..., это и так понятно)

GIT:
a) на текущем состоянии ветки master (аналог trunk) делается новая ветка (по сути получается пометка) именем v1.1.x - это ветка сопровождения;
b ) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.0 - это метка (в git'е, метка - просто именованное состояние)
Итого, ничего не фиксируется, только на каждое из перечисленных двух действий создаются служебные записи в хранилище (в Git'е оно локальное)

Идём дальше, исправление ошибок

Работаем над основной веткой (trunk/master).
Предположим, что приняли сообщение об ошибке в выпуске v1.1.0, от пользователя.
Нашли ошибку в ветке сопровождения, исправили. Далее:
SVN:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x)
2) копируем branches/v1.1.x в tags с именем v1.1.1 - это новая метка (предположим, что сразу выпускаем заплату не накапливая)
3) фиксируем изменения
4) сливаем текущее состояние ветки branches/v1.1.x в trunk (чтобы в главной ветке тоже было исправлено)

GIT:
1) зафиксировали изменения (исправление ошибки) в хранилище (ветка v1.1.x), с этого момента в хранилище появляется фактическая ветка которая содержит diff относительно точки ветвления
2) на этойже ветке (v1.1.x) создаётся метка с именем v1.1.1 (это по прежнему просто именованное состояние)
3) ---
4) сливаем текущее состояние ветки branches/v1.1.x в master (чтобы в главной ветке тоже было исправлено)

Итого ручной работы минимум, дубликатов минимум, а слияние в Git'е более наглядное/интуитивное.
Плюс Git отслеживает не только перемещения файлов по каталогам, но и функций из одного файла в другой (когда такое обнаруживается можно увидеть соответствующую пометку вместо полного diff'а)

Теперь рабочий цикл по второму типу веток - Функциональная ветка:
Необходимо провести эксперимент, нужно создать ветку от главной
SVN:
1) trunk копируется в branches с новым именем foo - это функциональная ветка;
2 ) рабочая копия переключается на эту ветку (опционально, зависит от стратегии работы с рабочей копией)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, осуществляется слияние
5) фиксируются изменения
6) функциональная ветка удаляется за не надобностью
7) фиксируются изменения
Итого имеем уже не нужную ветку в истории хранилища (оно пухнет)

GIT:
1) на текущем состоянии ветки master (аналог trunk) делается новая ветка именем foo - это функциональная ветка;
2 ) рабочий каталог переключается на эту ветку (обязательно)
3) делаются изменения, фиксируются в хранилище (многократно).
4) Принимается решение на слияние, переключают рабочий каталог на master
5) осуществляется слияние выбранной ветви (из списка ветвей) с master'ом (история правок самой функциональной ветви копируется при слиянии)
6) функциональная ветка удаляется за не надобностью
7) запускам сборщик мусора git gc, после этого удалённые ветви не востановить, т.к. они полностью удаляются из хранилища (опционально)
Итого, функциональные ветви, как коротко живущие можно полностью удалять из хранилища. А так как фнкциональные ветки явление частое и, можно сказать, основное, то они вносят наибольший вклад в вес.
Сверх того, отсутствие или перебои связи на твою работу вообще никак не влияют.

[Iron Bug]

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

Сообщение отредактировал Iron Bug - 27.1.2010, 20:37

[Litkevich Yuriy]

Я не сказал, но это может быть важно, Git в сравнении с SVN:
1)
В Git'е есть понятия веток и меток, это сущности встроенные в сам Git.
В SVN'е нет такого понятия, это человек для себя определил, что вот в этом каталоге я буду складывать копии другого каталога, например trunk. Т.е. понятие веток реализуется самим человеком.

2)
В Git'е версионному контролю подлежат только файлы, по сути он следит только за полным именем файла и изменением пути в этом полном имени.
В SVN'е под контроль версий можно добавлять и каталоги.
(попользовавшись Git'ом у меня на корню испарилась нужда добавлять под контроль версий каталоги)

3)
Я, до сих пор, не нашёл способа экспортировать правку/файл из Git-хранилища в произвольный каталог.
В SVN'е это делается элементарно.

4)
Git'у не принципиальны такие понятия, как переименование/копирование файла. При обнаружении изменений он показывает % соответствия одного файла другому, например так:

Т.е. на практике нужды в ручном (версионированном) переименовании, как в SVN'е, нет.

Вот снимок окна gitk:

Здесь жёлтенькие ярлычки - это метки (имена)
Зелёненькие - ветки (имена)
Ярлычки содержащие бледно красный текст "remotes/..." - это ветки/метки во внешнем хранилище, когда я принимаю из внешнего хранилища данные, то они не мешают основным, но я могу их в любой момент слить в нужную локальную ветку, или сделать от них (в любом их месте) новую локальную ветку.


П.С. это SVN-хранилище клонированное с помощью git-svn