crossplatform.ru

Здравствуйте, гость ( Вход | Регистрация )

6 страниц V   1 2 3 > »   
Ответить в данную темуНачать новую тему
> Git против SVN
Litkevich Yuriy
  опции профиля:
сообщение 26.1.2010, 19:49
Сообщение #1


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9648
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


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

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

SVN-Зеркало весит = 544 649 КиБ
Его Git-клон весит = 144 680 КиБ
т.е. более чем в 3,5 раза меньше.
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Kagami
  опции профиля:
сообщение 26.1.2010, 20:39
Сообщение #2


Старейший участник
****

Группа: Участник
Сообщений: 601
Регистрация: 2.2.2009
Пользователь №: 523

Спасибо сказали: 101 раз(а)




Репутация:   9  


У git'а проблемы с докачкой...
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 26.1.2010, 20:45
Сообщение #3


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9648
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


пока не напарывался.
Однако скорость git svn fetch заметно медленее чем svnsync (обновление зеркала SVN'а), я думаю, это из-за того, что git-svn - это Perl-сценарий, а не бинарь, как svnsync
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Tonal
  опции профиля:
сообщение 27.1.2010, 9:04
Сообщение #4


Активный участник
***

Группа: Участник
Сообщений: 452
Регистрация: 6.12.2007
Из: Новосибирск
Пользователь №: 34

Спасибо сказали: 69 раз(а)




Репутация:   17  


У git-а под виндой с русскими названиями файлов полная труба. :(
Опять же где-то читал, что текст в кодировках utf-16, utf-32 он воспринимает как бинарь...
Но скорость, распределённость и удобство ветвлений всё покрывают! :)
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 27.1.2010, 10:28
Сообщение #5


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9648
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Цитата(Tonal @ 27.1.2010, 12:04) *
У git-а под виндой с русскими названиями файлов полная труба.
у меня есть единственный файл - misc/протокол_Микродат.txt, проблемы ни какой не заметил
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
azure
  опции профиля:
сообщение 27.1.2010, 13:17
Сообщение #6


Студент
*

Группа: Участник
Сообщений: 60
Регистрация: 24.12.2009
Пользователь №: 1332

Спасибо сказали: 5 раз(а)




Репутация:   0  


Цитата(Kagami @ 26.1.2010, 19:39) *
У git'а проблемы с докачкой...

и в чем же суть проблемы? может, это проблемы сети, что килобайтная дельта не может быть передана без обрывов? Ну и git fsck никто не отменял
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Iron Bug
  опции профиля:
сообщение 27.1.2010, 14:25
Сообщение #7


Профессионал
*****

Группа: Модератор
Сообщений: 1571
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 218 раз(а)




Репутация:   12  


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

Сообщение отредактировал Iron Bug - 27.1.2010, 14:26
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 27.1.2010, 15:41
Сообщение #8


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9648
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


Цитата(Iron Bug @ 27.1.2010, 17:25) *
в git'e это удобно сделано?
по сравнению с Git'ом в SVN'е это вообще никак не сделано.

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

Цитата(Iron Bug @ 27.1.2010, 17:25) *
а в чём особое удобство ветвлений в 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
  опции профиля:
сообщение 27.1.2010, 20:36
Сообщение #9


Профессионал
*****

Группа: Модератор
Сообщений: 1571
Регистрация: 6.2.2009
Из: Yekaterinburg
Пользователь №: 533

Спасибо сказали: 218 раз(а)




Репутация:   12  


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

Сообщение отредактировал Iron Bug - 27.1.2010, 20:37
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение
Litkevich Yuriy
  опции профиля:
сообщение 27.1.2010, 21:03
Сообщение #10


разработчик РЭА
*******

Группа: Сомодератор
Сообщений: 9648
Регистрация: 9.1.2008
Из: Тюмень
Пользователь №: 64

Спасибо сказали: 807 раз(а)




Репутация:   94  


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

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

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

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

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

Вот снимок окна gitk:
Прикрепленное изображение

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


П.С. это SVN-хранилище клонированное с помощью git-svn
Перейти в начало страницы
 
Быстрая цитата+Цитировать сообщение

6 страниц V   1 2 3 > » 
Быстрый ответОтветить в данную темуНачать новую тему
Теги
Нет тегов для показа


1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0




RSS Текстовая версия Сейчас: 22.9.2018, 5:59