Які переваги систем управління версіями, які версують кожен файл окремо?

15

За останні кілька років я працював з декількома різними системами управління версіями. Для мене однією з принципових відмінностей між ними є те, чи вони файли версій окремо (кожен файл має свою окрему нумерацію версій та історію) або сховище в цілому ("фіксація" або версія являє собою знімок всього сховища) .

Деякі системи контролю версій "за файлом":

CVS
ClearCase
Visual SourceSafe

Деякі системи управління версіями "цілий репозиторій":

SVN
Git
Меркуріал

На мій досвід, системи управління версіями файлів лише призвели до проблем і вимагають набагато більше конфігурації та обслуговування для правильного використання (наприклад, "налаштування специфікацій" у ClearCase). У мене було чимало випадків, коли колега змінював незв’язаний файл і ламав те, що в ідеалі було б ізольованою лінією розвитку.

Які переваги цих систем управління файлами версій? Які проблеми виникають у системах керування версіями "цілого репозиторію", у яких системи управління версіями файлів не мають?

version-control

— Майк Даніелс
джерело

3

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

— блека

Вибачте, якщо це питання вийде як аргументативне. Це продукт деяких останніх розладів.

— Майк Даніельс

1

@Mike Daniels: Це не (принаймні для мене), оскільки ви чітко просите про переваги.

— блека

Ці дві точки зору є лише різними умовами. Будь-який аргумент на користь одного над іншим лише викликає контр-аргументи у партизанів іншої сторони. Наприклад, якщо ви хочете поведінку "повного повтору" в Clearcase, ви можете налаштувати свої параметри конфігурації за датою.

— mouviciel

У SVN є версія для файлу, чи це теж змінилося в останній версії?

— Клаїм

12

На мій досвід, не існує жодного: "цілий репозиторій" VCS суворо домінує над VCS "на файл".

— Рейн Генріхс
джерело

3

На файл має перевагу, коли ви створюєте продуктові лінії (кілька програмних продуктів) з одного сховища.

Деякі середовища, що займаються клієнтами, вимагають підтвердження того, що їх скидання коду ТОЛЬКО має зміни, які вони хотіли, а не інші зміни. Це досить просто, якщо номери версій файлів все одно однакові.

І це не випадковий приклад, який я витягнув з повітря.

Це сталося востаннє, коли я надсилав оновлення програмного забезпечення до армії США для системи, яку вони купували велику кількість у мого попереднього роботодавця. Вартість долара контрактів вимірювалася частковими мільярдами доларів (тоді, коли долари США коштували набагато більше)

Так це допомагає кілька разів.

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

Я підозрюю, що це набагато частіше в оборонному / аерокосмічному просторі, ніж у термоусадочних або веб-додатках.

— Тім Вілліскрофт
джерело

3

Але гілка всього сховища файлів також задовольняла б однакові потреби. Наприклад, у bzr гілки повністю не залежать від основної лінії до вашого об'єднання (або спільного використання сховища).

— edA-qa mort-ora-y

1

Я не можу придумати єдину ситуацію, коли гілка в системі "цілого репозиторію" не буде краще виражати необхідний стан, ніж покладатися на стан, зовнішній VCS, щоб визначити, які файли використовувати в VCS "на файл". Моя перша робота після uni використовувала RCS, купу сценаріїв для версії проекту та сценарій верхнього рівня для версії сценаріїв версій - абсолютний кошмар, і так, це було і для військового проекту. * 8 ')

— Марк Бут

@Mark Booth, замовник знав, які файли були змінені на те, які виправлення вони хотіли. Тож аудит фізичної конфігурації був за контрольним номером версії

— Тім Вілліскрофт

Я говорю, що версія + перевірений патч вимагає різної інформації в різних місцях, VCS та аудиторах. Маючи гілку в системі "цілого сховища", ці два стани записуються як окремі сутності. Тепер та сама інформація дублюється між СКС та системою аудиту, і завжди має відповідати. gitМожна навіть розрізняти автора та виконавця, тож ви можете зберігати ревізований сховище, де ви знаєте, хто створив виправлення (автор), і хто його провів (аудитор). Надайте нам зразкову ситуацію, і я переверну -1.

— Марк Бут

@ Марк стенд, які патчі? вони знали, що їх програмним забезпеченням є цей набір файлів A 1,01 B 1,05 D 1,55 E 1,44 F 1,01 і SVD для прийнятої ними версії міняли інформацію про зміни файлу, наприклад E міняли на виправлення дефекту 1104, стару версію 1.43, нову версію 1.44 . Небо допоможе нам, якби ми змінили F з версії 1.01. Ситуація була ще більш складною, оскільки були виправлені фактичні помилки, вони не хотіли змін. Ці люди хотіли мінімального набору змін, аби лише деякі особливості, вишневі за рік розвитку. Вибір помилок після спеціальних помилок.

— Тім Вілліскрофт

3

Немає жодної переваги для версії для кожного файлу.

З іншого боку, недоліки - це багато і проявляється.

— Вільям Пейн
джерело

0

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

— Арвінд Чінія
джерело

0

Немає переваги у підході до файлів, коли у вас є пов’язані файли. Який найпоширеніший випадок у налаштуваннях розвитку.

У кількох своєрідних випадках - / тощо або. Файли у вашому домашньому каталозі в Unix - це єдине, що у мене зазвичай - ви обробляєте (здебільшого) непов'язані файли. І тоді наявність системи, яка наполягає на збереженні синхронізації непов'язаних змін, може стати неприємністю.

— AProgrammer
джерело