Чи є незручність злиття в SVN до версії v1.5 застарілою до теперішнього часу, коли відсутність метаданих вже не відбувається?

Я починаю працювати з SVN, і так багато джерел кажуть, що об'єднувати SVN дуже важко порівняно з інструментами DVCS. В останні питання я міг би знайти тут на РЕ з 2012 року.

Іноді згадується, що причина полягає в тому, що SVN до v1.5 не мав метаданих, але SVN зараз у версії 1.8.9.

Зважаючи на те, що SVN зараз набагато зріліший ніж v1.5, і особливо той факт, що ми не використовували SVN 1.5, щоб ми не страждали від згаданої відсутності метаданих - чи є ще велика обґрунтованість у цих аргументах проти SVN?

Я розумію, що DVCS має зовсім інший підхід, який часто є більш бажаним, але для тих, хто "повинен" використовувати SVN з будь-якої причини, злиття вже насправді не "пекло", чи не так?

version-control svn merging

— Torben Gundtofte-Bruun
джерело

@ TorbenGundtofte-Bruun - У мене зараз немає часу, щоб дати таку відповідь, але я скажу "не бійтеся SVN". Він має обмеження, але це стосується і DVCS.

— kdgregory

Відповіді:

Це добре працює, якщо ви дотримуєтеся простих випадків , але є деякі складні, які цього не роблять.

Обмеження, про які я можу придумати:

Він може знайти самого останнього предка, лише якщо він знаходиться на одній із задіяних гілок. Так що, якщо ви створюєте branches/thisі branches/thatяк з , trunkа потім спробувати об'єднати , branches/thisщоб branches/thatвін не знатиме , що робити. Що означає, що ви можете злити гілку лише з її батьківською родиною. Ви можете зіткнутися з цим, якщо запустити дві гілки функцій і пізніше зрозуміти, що функції взаємозалежні і потрібно їх поєднувати.
Хоча він стверджує, що він може відслідковувати перейменування, об'єднання гілок, коли файли переміщувались з одного боку та змінювались з іншого, не завжди знаходить потрібні файли для злиття, а виправлення вручну - дещо стомлююче, оскільки не залишає необхідної інформації ніде рукою.
Додані файли іноді викликають помилкові конфлікти при пізніших злиттях.
Оскільки у підривної системи немає окремої концепції гілки, ви можете об'єднати лише підгрупу проекту, і це може призвести до великого безладу досить швидко. Настійно рекомендується подбати про те, щоб завжди зливати цілі гілки. На жаль, чомусь властивості інформації про злиття з’являються у підкаталогах, навіть якщо вони здаються зайвими, і об'єднання було зроблено правильно для всієї гілки.
І останнє, але не менш важливе - це повільно . Об'єднання в проект будь-якого серйозного розміру часто займає кілька хвилин, коли більшість DVCS можуть це робити за секунду.

— Ян Худець
джерело

+1, чудова відповідь. Справа про спільного предка - це те, на що я повинен бути уважним. Чи є у вас посилання на ці факти?

— Doval

@Doval: досвід.

— Ян Худек,

можливо також варто згадати, що svn також не має окремої концепції тегів

— jk.

Що стосується вашої першої кулі (спасибі за дуже чітке пояснення!), Чи не можна її вирішити, використовуючи гілку накопичення, яка має ту саму точку розгалуження, що й гілки функцій? (на основі Vance98 ) Чи справді проблема виникає лише тоді, коли дві гілки функцій мають різні точки відгалуження?

— Torben Gundtofte-Bruun

@ TorbenGundtofte-Bruun: Останній звичайний предок не повинен бути точкою гілки. Ви можете знайти його самостійно і підказати підривникові застосувати зміни між певними переглядами прив’язки. Але проблема полягає в тому, що це багато роботи, і ти повинен усвідомити, що ти повинен це зробити, тому що підрив не обов'язково кидає вгору руки, кажучи, що він не може злитися. Натомість він може знайти спільного предка, який не є останнім та породжує безліч конфліктів.

— Ян Худек

З мого досвіду, об’єднання в SVN було «зафіксовано» у версії 1.6. Я працюю і в Mercurial, і в SVN, і оскільки версія 1.6 SVN, злиття, здається, приблизно однакова, як на обох платформах. Єдиним винятком може бути те, що вам потрібно пам’ятати, щоб надати цей --reintegrateпараметр під час об’єднання з гілки назад у магістраль за допомогою SVN.

Це лише мій досвід роботи. Я нічого не знаю про внутрішні місця SVN.

— Чарльз Е. Грант
джерело

1.8, нарешті, може виявити «реінтегрувати» справу, на щастя. Але це піклується лише про останнього спільного предка на місцевому або віддаленому рівні. Він все ще не може знайти його на третьому відділенні.

— Ян Худек