Справа в тому, що commit - це не просто заливка змін. Сутність цієї операції полягає в тому, що зміни, зроблені локально, перетворюються в зміни, які можуть бути успішно додані в репозиторій і зафіксовані в ньому у вигляді чергової ревізії. При цьому локальні зміни завжди виражені у вигляді відмінностей щодо останньої ревізії, про яку відомо локально (тобто ревізії, яка була під час останнього update), а в репозиторій можуть бути додані лише такі зміни, які виражені у вигляді відмінностей щодо останньої ревізії самого сховища.
У найпростішому випадку, коли в репозиторій не було додано нічого з боку, перетворення змін зводиться до того, щоб не робити нічого, оскільки зміни і так вже виражені у вигляді відмінностей щодо останньої ревізії в репозиторії. Тому операція commit стає очевидною і виглядає, як проста заливка змін. У разі ж, коли з моменту останнього update в репозиторії вже з'явилося щось нове, спроба зробити тривіальний commit провалюється і доводиться проходити всю процедуру повністю, тобто спочатку пристосовувати свої локальні зміни до тих іншим змінам, які вже були зафіксовані в репозиторії кимось іншим, і тільки потім заливати їх і фіксувати.
Коли ми заливаємо в репозиторій зміни, зроблені в робочій копії, необхідність робити commit в самому кінці очевидна. Адже в репозиторії ще немає наших локальних змін, оскільки попередня спроба зробити тривіальний commit провалилася. Не так очевидна ця необхідність в ситуації, коли ми об'єднуємо одну гілку з іншого прямо в репозиторії за допомогою merge. Справа тут ось в чому. Насправді, операція commit грає ще й роль підтвердження. Заливка в репозиторій нових змін як в тривіальному випадку, так і після адаптації завжди виконується після того, як користувач побачив остаточний варіант, тому його підтвердження, необхідне для фіксації чергової ревізії, ніби передбачається і дається тим же самим commit'ом. А ось про об'єднання гілок в репозиторії такого сказати не можна. Результат об'єднання гілок зазвичай відрізняється від того, що було в останніх ревізіях як однієї гілки, так і інший. Він являє собою абсолютно нову ревізію. І навіть в тому випадку, коли участь користувача в самому об'єднанні гілок не потрібно, від нього все одно потрібно отримати підтвердження після того, як буде отримано остаточний варіант нової ревізії. Саме для цього і потрібен commit після merge. Якщо об'єднання пройшло на автоматі, то commit грає лише роль підтвердження, яке необхідно для фіксації будь-якої ревізії в репозиторії.
відповідь дан 29 Серпня '12 в 6:11
- Непогано написано, але результат об'єднання двох гілок може впливати тільки на одну з цих гілок, друга ж гілка завжди залишається без змін. Це вірно як для svn merge, так і для svn merge --reintegrate. - Costantino Rupert 10 Вересня '12 о 8:02
Типовий патерн роботи такої: checkout → працюємо → commit → перерву → update (можливо з merge) → працюємо → commit і т.д.
відповідь дан 29 Серпня '12 о 5:35