Черепаха SVN: Вирішити конфлікт, використовуючи "їх". Що це означає?

75

Хтось може пояснити різницю між наступними двома варіантами Tortoise SVN у конфліктних файлах:

Вирішуйте конфлікти, використовуючи "їх".
Вирішити конфлікт, використовуючи "мій".

На додатковій записці. Чому на землі ніхто ніколи не повідомляв про це заплутане використання термінології як про помилку?

svn version-control tortoisesvn

— Мухаммед Хасан Хан
джерело

4

Плутанина, мабуть, через нерозуміння контексту "їхнього" та "мого"

— Ігор Пащук

17

Я прибув сюди через цю плутанину, хоч і не в Tortise SVN, а з командного рядка. Під час оновлення в командному рядку параметр надається як "їх конфлікт", що є неоднозначним щодо того, чи буде його вибір тримати його в конфліктному стані, або вирішити.

— похл

3

Це ще більше бентежить, коли ви об'єднуєтесь, і він перемикає термінологію на "локальний" та "сховище". Мені не найменш зрозуміло, що саме в цьому випадку.

— JohnOpincar

7

Я знову і знову повертаюся на цю сторінку. Чому вони не просто сказали "віддайте перевагу локальним змінам репозиторіям" і "віддайте перевагу змінам репозиторію локальним" або щось подібне, що логічно і легко зрозуміти. Я знаю, що це трохи довше, але в цьому випадку менше, а точно не більше.

— Компонент 10

3

Безумовно неоднозначно. Перевірте чужу гілку, а потім об’єднайте зміни з гілкою, яку ви зробили в неї. Подивіться, наскільки чітким здається тоді ваш проти мого.

— Хлопець із програмування

55

Вирішити конфлікт, використовуючи "їх", означає, що при спробі перевірити два файли, які мають суперечливі редагування, SVN відхилить ваші зміни та замість них використає зміни інших осіб.

Вирішити конфлікт, використовуючи "мій", означає, що ви відхилите їх зміни та використаєте свою версію файлу.

— Брендон
джерело

4

Перегляньте зображення, яке багато про що пояснює про це: tortoisesvn.net/docs/release/TortoiseMerge_en/…

— Стефан

3

Ця відповідь взагалі не стосується двозначності навколо їхнього та мого. Щойно мене попросили об’єднати зміни з гілки, над якою я працював, у гілку, над якою працював хтось інший. У цьому випадку зміни, які я вважаю «своїми», це зміни з мого відділення. Однак, якщо я прийму "мої" зміни, я фактично відхилюю зміни від мого відділення.

— Хлопець-програміст

Я не бачу mineв меню "Вирішення конфлікту за допомогою ". Чи неможливо забезпечити об’єднання моїх змін із їх змінами?

— SearchForKnowledge

1

Так, я не розумію цієї відповіді. Немає "іншої особи"

— гальмує

42

Я хотів додати весь список для подальшої довідки:

(e)  edit             - change merged file in an editor
(df) diff-full        - show all changes made to merged file
(r)  resolved         - accept merged version of file

(dc) display-conflict - show all conflicts (ignoring merged version)
(mc) mine-conflict    - accept my version for all conflicts (same)
(tc) theirs-conflict  - accept their version for all conflicts (same)

(mf) mine-full        - accept my version of entire file (even non-conflicts)
(tf) theirs-full      - accept their version of entire file (same)

(p)  postpone         - mark the conflict to be resolved later
(l)  launch           - launch external tool to resolve conflict
(s)  show all         - show this list

— неркн
джерело

33

Я згоден.

Мені здається, що було б зрозуміліше, якби там було сказано:

Вирішення за допомогою сховища (їхнього)
Вирішення за допомогою робочої копії (моєї)

— james2code
джерело

3

На мою думку, найкращі відповіді як конфлікти можуть відбуватися без участі другої людини (наприклад, при використанні git flow з декількома гілками).

— Крістоф

Тепер, що робить "позначити як вирішене"? це використовує моє чи їхнє ?!

— FIV

2

Він просто видаляє прапор конфлікту та використовує поточний стан об’єднаного файлу. Зазвичай ви переглядаєте конфлікти та виправляєте будь-які проблеми, а потім відзначаєте це як вирішене. Два варіанти, обговорені в цьому питанні, - це варіанти ярликів для вирішення конфліктів, використовуючи лише вашу версію або версію в репо. Це автоматично встановлює його як вирішене, тоді як при ручному виправленні конфлікту потрібно "позначити як вирішене".

— james2code

7

Злиття командного рядка SVN викликає заплутаність, особливо при об'єднанні гілки назад у стовбур. "Мої зміни" - це зміни, які я зробив у гілці, але це було б неправильно на думку SVN . Щоб реально ускладнити ситуацію, SVN посилається на шляхи як ДЖЕРЕЛО, ЦІЛЬ і ГОЛОВА в довідці командного рядка.

Ось проста відповідь , якщо ви запустите цей оператор злиття з каталогу C: \ Project1 \ Trunk

svn merge -r 60:68 C:\Project1\branches\UpdatesToProject1

"Шахта" - це каталог, з якого запускається SVN (C: \ Project1 \ Trunk).

"Їх" - це каталог, який ви об'єднуєте і вказали в командному рядку (C: \ Project1 \ branch \ UpdatesToProject1)

Було б дійсно приємно, якби SVN дав шляхи, на які посилаються MINE та THEIRS.

— К Кімбл
джерело

2

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

— iank

6

BuzzAnn правильний. mine проти їхнього є неоднозначним, оскільки те, що знаходиться у сховищі, також може бути моїм. Однозначна відмінність - це сховище від локальної копії .

— Дейв Сіт
джерело

1

Якщо ви визнаєте, що те, що знаходиться у сховищі, більше не є (виключно) вашим, воно ділиться з усіма, хто має доступ, тоді це може бути зрозуміліше.

В цьому контексті:

"їх" означає "спільний код команди у сховищі" "мій" означає (мій) "робочу копію" (можливо, на локальній машині)

Отже: "використання їх" замінює вашу робочу копію спільною копією, відкидає ваші зміни, які існують на вашому локальному комп'ютері. "використовуючи мій", вирішивши, що код у вашій робочій копії - це те, що слід зберігати в сховищі, відкидаючи те, що зараз знаходиться в репо.

— птерміган
джерело