В чем разница между GIT и SVN, когда дело доходит до разрешения конфликтов слияния

Я продолжаю слышать, что ветвление в git намного проще, чем в SVN, потому что легче объединить ветку обратно в trunk/master. Я прочитал несколько руководств, но они охватывали только основные конфликты слияния («Алиса изменила строку 8 в code.cpp, и в то же время Боб изменил строку 8 в code.cpp...»), и нет никаких различий между SVN и все другие распределенные системы управления исходным кодом.

Можете ли вы привести примеры изменений в ветке, которые вызовут проблемы в репозитории SVN, но будут изящно обработаны git?


git conflict merge branch svn
person chalup    schedule 30.03.2010    source источник
comment
Это очень похоже на этот вопрос здесь: stackoverflow.com/questions/2475831/merging-hg-git -vs-svn так что вы можете взглянуть на это.   -  person welp    schedule 30.03.2010
comment
может svn недавно догнал? Не знаю, я мало им пользуюсь. может ли svn непрерывно сливаться с удаленной ветки?   -  person hasen    schedule 30.03.2010

Ответы (2)


arrow_upward
3
arrow_downward

Наконец-то у меня появилось время повозиться с ветками/слиянием с git и svn, и я нашел случай, который убивает svn, но прекрасно работает с git:

Допустим, проект состоит из этих файлов:

/main.cpp
/sub1/sub1.cpp
/sub1/sub1.h
  1. Создать ветку
  2. В магистрали переместите sub1.* в корневой каталог, удалите подкаталог sub1.
  3. В ветке внесите некоторые изменения в /sub1/sub1.cpp
  4. В транке внесите некоторые изменения в /sub1.cpp
  5. Объединить ветку и ствол.

SVN теряет все изменения, сделанные в ветке в пункте 3, аналогичные изменения в git отлично сливаются. Этого достаточно, чтобы я отверг SVN как систему контроля версий для любого проекта, требующего ветвления.

person chalup    schedule 19.04.2010

arrow_upward
2
arrow_downward

hgInit.com связан с Mercurial, но даст вам очень хороший обзор разницы между DVCS и SVN для слияния конфликты.

Причина, по которой у Subversion возникают проблемы со слиянием, связана со способом хранения истории версий. Subversion любит думать о ревизиях. Ревизия — это то, как выглядела вся файловая система в определенный момент времени. В Mercurial вы думаете о наборах изменений. Набор изменений — это краткий список изменений между одной и следующей ревизиями.

Таким образом, Subversion сравнивает целые файлы при слиянии, в то время как Mercurial (или Git) сравнивает каждый набор изменений по отдельности. Конфликты возникают гораздо реже при работе с наборами изменений.

person Benjamin Ortuzar    schedule 30.03.2010
comment
Орли? Я вижу только базовую конфликтную ситуацию, описанную в моем вопросе. - person chalup; 30.03.2010