Що SVN робить краще, ніж Git? [зачинено]


293

Не викликає сумнівів, що більшість дебатів щодо інструментів програміста спрямовані або на особистий вибір (користувачем), або на упор на дизайн , тобто оптимізацію дизайну відповідно до конкретних випадків використання (за допомогою конструктора інструментів). Текстові редактори - це, мабуть, найвизначніший приклад - кодер, який працює в Windows під час роботи та кодує в Haskell на Mac вдома, цінує інтеграцію між платформами та компіляторами, тому вибирає Emacs над TextMate тощо.

Рідше, що нещодавно введена технологія справді, демонстративно перевершує існуючі варіанти.

Це насправді так з системами управління версіями (VCS), зокрема, централізованими VCS ( CVS та SVN ) проти розподілених VCS ( Git та Mercurial )?

Я використовував SVN близько п’яти років, а SVN зараз використовується там, де я працюю. Трохи менше трьох років тому я перейшов на Git (і GitHub) для всіх своїх особистих проектів.

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

Тільки висновок , який я зробив виходячи з цього є те , що у мене немає ніяких даних - НЕ то, що Git краще, і т.д.

Я здогадуюсь, що такі зустрічні приклади існують, звідси і це питання.


3
@jokoon: Ефективна з точки зору чого? Напевно, не швидкість, оскільки навіть швидкий Ethernet повільний порівняно з локальними операціями.
maaartinus


4
Я завжди думав, що Гіт дуже цінується. Це примха, і програмісти не впевнені у придумках - незважаючи на численні протидії цій думці. Як і всі в цьому світі, всі хочуть нової блискучої іграшки (Git). Гіт може бути хорошим - або навіть чудовим для деяких людей - але він ніколи не був кращим за SVN, коли мислив об’єктивно.
купив777

3
Я подумав, що SVN все ще добре використовувати, крива навчання хороша, ніж GIT.
Cheung

5
Нещодавно це питання було зупинено як основна думка. Ця класифікація неправильна; зауважте, що питання було відкритим тривалий час; що є багато питань про чесноти DVCS, і що питання не запитує, чи це краще (думка), а що це робить краще. Відмінності не в думці, а в тому, чи загальний продукт - це хитро (але це не суть цього питання).
Еймон Нербонна

Відповіді:


207

Субверсія є центральним сховищем

Хоча багато людей хочуть мати розподілені сховища для очевидних переваг швидкості та декількох копій, є ситуації, коли центральний сховище є більш бажаним. Наприклад, якщо у вас є якийсь критичний фрагмент коду, до якого ви не хочете, щоб хтось мав доступ, ви, ймовірно, не хочете ставити його під Git. Багато корпорацій хочуть залишати свій код централізованим, і (я думаю) всі (серйозні) урядові проекти знаходяться в центральних сховищах.

Підрив - це звичайна мудрість

Це означає, що багато людей (особливо менеджери та начальники) мають звичний спосіб пронумерувати версії та бачити розвиток як "єдиний рядок" по ходу часу, який укорінюється в їх мозок. Без образи, але ліберальність Гіта непросто проковтнути. Перший розділ будь-якої книги Git говорить про те, щоб викреслити зі свого розуму всі звичайні ідеали і почати заново.

Підрив робить це в один бік, і більше нічого

SVN - система управління версіями. У нього є один спосіб зробити свою роботу, і всі роблять це так само. Період. Це полегшує перехід до / з SVN з / в інший централізований VCS. Git НЕ навіть чистий VCS - це файлова система, має безліч топологій, як налаштувати сховища в різних ситуаціях - і немає жодного стандарту. Це ускладнює його вибір.

Інші переваги:

  • SVN підтримує порожні каталоги
  • SVN має кращу підтримку Windows
  • SVN може перевірити / клонувати під-дерево
  • SVN підтримує ексклюзивний контроль доступу, svn lockякий корисний для важко об'ємних файлів
  • SVN легше підтримує бінарні файли та великі файли (і не потрібно скрізь копіювати старі версії).
  • Додавання фіксації передбачає значно менше кроків, оскільки не відбувається жодного натискання / натискання, а ваші локальні зміни завжди неявно спираються на основу svn update.

55
"Підрив робить це одним способом" - так я і думав, поки не почав свою теперішню роботу. На моїй нинішній роботі мій начальник, який стверджує, що не має проблем з довірою, налаштував сервер на запит блокування. У нашій системі не відбувається злиття. Файли заблоковані у сховищі, і ніхто більше не може записати їх без блокування. Контроль зверху вниз, для тих, чиї конституції цього вимагають, - безумовно, щось, що svn робить краще, ніж git.
Dan Ray

14
Однією з переваг центрального сховища є легкість створення резервних копій. Якщо весь зареєстрований код знаходиться в одному місці, а в одному місці є резервне копіювання за межами сайту, ви нічого не втратите, якщо ваш офіс згоряє. За допомогою DVCS, якщо ви не робите резервні копії на машинах розробника за межами сайту, ви втрачаєте все, що не було висунуто на сервер, який резервно створено за межами сайту.
Пол Томблін

94
Чому не можна використовувати git централізовано? Просто майте одне центральне сховище, і ваші диски можуть клонувати, тягнути і штовхати так, як вони перевіряють, оновлюють і здійснюють.
Девід Торнлі

29
@PaulTomblin - залежно від робочого процесу Git може забезпечити кращі резервні копії. Наприклад, ми використовуємо приватні репозитори github, і я часто підштовхую свій код до гілок. Якщо це роблять мої колеги git fetch origin, у кожного з них є резервна копія мого коду, а також будь-яка резервна копія, яку надає сам Github. (Ми регулярно обрізаємо зрощені гілки, як локально, так і на Github.)
Натан Лонг

52
Ви, здається, маєте на увазі, що центральний є більш безпечним для великих компаній або роботи уряду. Це просто неправда. Якщо у вас на комп’ютері є копія коду, у вас є копія коду. Не має значення, прийшов він з центрального сервера або центральної файлової системи, що містить сховище DVCS.
Джон Фішер

131

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

І невелика крихітна користь: Subversion може відслідковувати порожні каталоги. Git відстежує вміст файлу, тому каталог без жодного файлу не з’явиться.


11
Робота з під деревами - це IMHO - єдине, що SVN має над GIT. Точка прийнята, порожні каталоги приємні, але теж не потрібні (і їх можна обробити). Якби підмодулі git та git subtree були менш заплутаними, багато людей не стримували б перехід до GIT. Інші переваги, про які згадують деякі люди, зводяться до (менталітету розробників). Наприклад, якщо вам потрібно зверху вниз, це добре. Я б не працював для вас.
До

3
Смішно, як це єдині речі, які можна аргументувати на користь SVN (та іншого централізованого контролю версій)
dukeofgaming

1
Чому це смішно? - новіші системи навчаються у старих систем. Існує навіть користь з RCS через git: Файли історії можна легко редагувати вручну, і ви можете мати гілки на окремі файли. Але рішучість передбачає, що функції втрачаються ...
johannes

3
Я чув про ігрову компанію, яка використовує SVN над GIT саме з цієї причини - коли ви говорите про сховище розміром багато ГБ, воно раптом стає важливим!
Джеймс

18
Станом на версію git 1.8.0, тепер ви можете використовувати git subtreeкоманду, щоб виконати саме це. Остання перевага субверсії кусає пил :) Деталі тут: github.com/gitster/git/blob/… Примітка: Хоча це посилання на проект github, git-subtree тепер є частиною основної дистрибуції git.
Карл

51

Я можу придумати три. По-перше, це досить просто простувати, особливо для не розробників. Концептуально це набагато простіше, ніж варіанти DCVS . Друге - зрілість, особливо TortoiseSVN у Windows. Хоча TortoiseHg наздоганяє швидко. По-третє, природа звіра - лише зображення файлової системи, де ви можете перевірити речі з будь-якого рівня дерева - може стати дуже зручною у деяких сценаріях - як, наприклад, версія різних різноманітних файлів конфігурації у десятках серверів без десятків сховищ.

Це не означає, що ми не переносимо всю розробку на Mercurial.


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

12
@jhocking: Я не люблю SVN, але якщо хтось скаже мені: "Мені не подобаються ці нові речі з DVCS, тому я залишатимусь із CVS", то я обов'язково рекомендую це: це, як мінімум, легка дорога частково здоровий VCS ;-)
Йоахім Зауер

4
@jhocking Нові способи не завжди найкращі для будь-яких обставин. Він пам'ятає про стару історію про те, що NASA витрачає мільйони доларів на розробку ручки, яка може писати в 0 г З іншого боку, космонавти зробили олівцями. Іноді старі способи є кращими, ЗАРАЗ ЗДАЙТЕ МОЙ ПРАВО!
maple_shaft

25
@maple_shaft, а іноді й ні. snopes.com/business/genius/spacepen.asp
Пітер Тейлор

3
Легке вподобання є дуже суб'єктивним і багато в чому ґрунтується на тому, як ви намагаєтеся вписати нові знання в те, що ви вже можете знати. Це також має велику різницю в тому, що ваше джерело навчання. Якщо ви переглядаєте чоловічі сторінки, удачі. Якщо вас навчає хороший вчитель, який уже вподобає, ви це зробили. Я виявив, що git отримав надзвичайний сенс після перегляду кількох хороших відео на YouTube. Якщо ви розумієтесь від того, хто вже перегнав його до простого ядра, то зрозуміти що-небудь простіше.
WarrenT

32
  • SVN-сховища є більш керованими з точки зору менеджера та адміністратора ( ACL + методи аутентифікації + гаряча копія + дзеркала + дамп)
  • SVN * -качки легше впроваджувати та підтримувати
  • svn:external володіє більшою потужністю та гнучкістю, ніж субмодулі
  • Дерева сховищ на основі файлової системи простіші у використанні, ніж монолітні сховища з логічним розділенням
  • SVN має більше різних клієнтських інструментів
  • SVN має сторонні веб-інтерфейси, набагато кращі, ніж Git's
  • SVN не розбиває ваш мозок

23
Не зламає ваш мозок? Хочете навчити мене легко зливати гілки з конфліктами у SVN?
WarrenT

4
"Кращі" інструменти / передні, це рухома мета. Інструменти вдосконалюються з обох сторін. Ніхто з нас не знає, які інструменти будуть доступні через кілька років. Ця оцінка 10 місяців тому може з часом легко змінитися і може бути несвіжою. Я хотів би бачити змістовні відповіді.
WarrenT

6
Деревні конфлікти? Перевірка. Так чи ні для всіх варіантів? Ні. Svn створений для того, щоб розлютити. Очистити команду робочої копії? Ні. Оновити не вдається очистити неперевірені файли.
Warren P

1
Якщо видалити все та перевірити ще раз, ви очистите неперевірені файли.
jgmjgm

Мені подобається ваша остання ідея, Гіт розбив мій мозок: '(
Лука

24

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

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

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


Центральність - це питання не міфу, а факту. Ніхто не може перешкодити мені щось змінити. За допомогою cvcs вони можуть перешкодити мені щось центрально змінити. Те саме в dvcs. Слово "фіксувати" в cvcs співвідносить фіксувати і натискати.
Warren P

@JonathanHenson: це, безумовно, не єдина причина, по якій Торвальдс ненавидить SVN. SVN може бути централізованим і може бути кращим CVS, але це навряд чи робить його хорошим програмним забезпеченням. Торвальдс ненавидить CVS / SVN не тому, що вони централізовані, а тому, що він вважає, що це патетично погане програмне забезпечення. Право чи ні, вирішувати вам, але ви побачите величезний успіх обох Linux (і Android) - що працюють на мільярдах пристроїв-- і Git - що в значній мірі сприймає світ штормом--, я » я подумайте двічі, перш ніж погодитися з ним. Лекція, яку Торвальдс читав у Google на Git років тому, дивовижна.
Седрік Мартін

Лол. Ваш менеджер правий, щоб жахнувся, що немає належної системи резервного копіювання. Просто сказати "але його DVCS, щоб у когось була копія" не летить - я знаю, коли я побачив, як git використовувався в останньому місці, у них буквально не було копій деяких репостів. Зауважте, що блокування може бути корисним для деяких ситуацій, і git не спрацьовує в цьому плані - якщо ви не маєте магічного інструмента злиття зображень чи інших двійкових файлів. git дійсно працює лише для текстових файлів.
gbjbaanb

22

Мої причини:

  • зрілість - і сервер, і інструменти (наприклад, TortoiseSVN)
  • простота - менше задіяних кроків, фіксація - це вчинення. DVCS, такі як Git і Mercurial, включають фіксацію, а потім натискання.
  • бінарне керування - SVN обробляє бінарні виконувані файли та зображення краще, ніж Git / Hg. Особливо корисно для .NET-проектів, оскільки мені подобається перевіряти інструменти, пов’язані з побудовою, на контроль джерел.
  • нумерація - SVN має читабельну схему нумерації фіксації, використовуючи просто цифри - простіше відстежувати номери ревізії. Гіт і Хг роблять це зовсім по-різному.

1
"схема числення нумерації" можлива лише за наявності канонічних стовбурів. Інакше хто з них отримує основну нумерацію?

1
+1 нумерування у svn. Цей номер унікальний. Є інструменти для використання цього номера як частини додатка-версії xx.yy.zz.12882, де 12882 - номер версії svn. Якщо виникає проблема з виробництвом, ви можете запитати у версії номер версії, і у вас є точна версія svn-редакції, де було створено програмне забезпечення
k3b

22

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

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

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

Я намагаюся зробити те, що якщо ви невелика команда, яка працює над середнім та малим проектом, і ви вже знайомі зі SVN, тоді використовуйте її. Це, звичайно, краще, ніж CVS або (здригаючись) SourceSafe , і для того, щоб створити сховище, мені не потрібно більше п'яти хвилин. Гіт іноді може бути надмірним.


3
Дійсно? Тоді я б запропонував вам поглянути на копалини .
Спенсер Ратбун

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

@SpencerRathbun, дякую! Мені доведеться поглянути на це. Я не так люблю svn, як маю неприємність до git.
maple_shaft

10
@Spencer - навпаки, як користувач обох, gitі hgя б запропонував меркуріал для тих, хто вважає, що gitце занадто багато. TortoiseHG був би дуже знайомий всім, хто звик до TortoiseSVN (він навіть має ті самі накладки Explorer у Windows). Це, звичайно, набагато простіше, ніж VSS, і я був би здивований, якби знадобилося більше декількох секунд, щоб налаштувати hg-репо, здійснити початковий стан і клонувати його на спільний диск.
Марк Бут

@MarkBooth Як зазначено в оригінальному запитанні, я думаю, що це питання бажань і потреб. На моєму нинішньому робочому місці до того, як я туди потрапив, не було репо. Мені потрібно було щось, що мав би всі, або більшість, інструменти для проектування, які я хотів згорнути разом, було просте у використанні, зберігало все замість дельти, і працювало б розподіленим для команд з 1 або 2 людей на декількох машинах.
Спенсер Ратбун

20

Це все відносно, і як сказав maple_shaft, якщо один працює на вас, не змінюйте!

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


2
Як SVN справляється з ними краще? Git вважає кожен файл BLOB.
WarrenT

4
@WarrenT через робочі процеси, з git ви багато розгалужуєте та об'єднуєте (або чому це турбуєтесь), і просто не можете реально об'єднати бінарні файли. Отже, ви часто ставите властивість "замок блокування" на бінарні файли у SVN.
gbjbaanb

1
Деякі бінарні файли (теоретично) можуть бути об'єднані, наприклад, документ ODT.
Стипендіати Дональ

18

Корисність. Це не насправді заслуга Subversion, а скоріше TortoiseSVN 's .. TortoiseGit існує, але все ще має довгий шлях, щоб відповідати TortoiseSVN.

Якщо ви запитали, що Git робить краще, ніж SVN, я відповів би GitHub . Дивно, як сторонні інструменти роблять настільки величезну зміну.


1
Асамблея (для будь-якої підтримуваної SCM - SVN у списку) краща за github, я думаю
Ледачий борсук

Є також smartgit, GitXL тощо, програми, які спрощують використання git способу
wirrbel

@LazyBadger, ніколи про це не чув.
Pacerier

16

Коли вам не потрібно розгалужувати та об’єднувати , SVN (із TortoiseSVN в Windows) дуже легко зрозуміти та використовувати. Git надмірно складний для простих випадків, оскільки він намагається зробити розгалуження / злиття легким.

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


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

Кожен раз, коли вам потрібно робити виправлення у старих версіях, вам потрібно розгалуження та об'єднання.

1
Чому люди не вважають думкою, що меркурій легше, ніж svn чи git?
Warren P

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

14

Добре, мій дідусь міг би використовувати SVN на своєму комп’ютері Windows XP, але у нього виникнуть проблеми з використанням Git. Можливо, це скоріше досягнення TortoiseSVN над TortoiseGit , але я думаю, що це скоріше пов'язане з тим, що Git за своєю суттю більш потужний і, таким чином, складніший, і було б безглуздим притупляти його до того ж рівня.

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

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


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

11

На роботі я не зміг переключити розробників зі SVN на будь-який DVCS з двох причин:

  • Часткова перевірка (як-от лише три папки різної глибини в дереві проекту)
  • Блокування файлів (звіти про двійковий формат)

8
  • Почуття безпеки під час виконання "svn". Оскільки коміти переходять на сервер, я не можу зробити виправлення, яке можу зробити, щоб стерти зміни після їх внесення. У git, комісії локальні, тому, поки я не натисну, бродячий 'rm -rf', і все закінчиться.
  • Коміти аутентифіковані. За замовчуванням у git я можу сказати, що я вчиняюсь як хто.
  • Менше команд навчитися для щоденного використання. 'svn checkout', 'svn up' та 'svn commit' дадуть вам досить далеко.
  • Спільні каси працюють набагато приємніше. Коли ви переходите до фіксації, він запитує ваше ім'я користувача / пароль, вам не потрібно пам'ятати, щоб передавати певні аргументи командного рядка. Іноді на роботі у нас є спільна машина з загальним замовленням svn якогось проекту. Хтось може сказати "Боб, ти можеш це подивитися на цій машині", і він може, і він може здійснити свої зміни як його користувач без будь-яких гвинтів.
  • Макет сховища. Ви можете мати парасольковий проект та підпроекти та вибрати, що потрібно перевірити, коли.
  • Ревізійні номери збільшують цілі числа.
  • Призначений для робочого процесу центрального сховища.

+1 для проблеми аутентифікації. Git зобов’язані підписувати, а підписи потрібно перевірити, що важко.
Крістіан

6

Інші люди опублікували досить непогані відповіді, але як щодо дозволів? Використовуючи Subversion через SSH, ви можете зробити окремий обліковий запис на своєму сервері для SVN. Різним розробникам може бути наданий різний доступ до різних частин сховища. Чи може GIT це зробити? Я думаю, що є гітоліт, але він просто не здається мені гнучким або надійним, і я не знаю тих, хто насправді ним користується.


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

1
благословенне сховище керівника проекту та лейтенанти надають контроль над тим, хто може здійснити. Git repo, опублікований на сервері з підтримкою http-auth (використовуючи ті самі модулі apache, який робить svn), робить аутентифікацію і каже, хто може клонувати / перевіряти що. Звичайно, це не настільки детально, як можуть бути права доступу до svn для каталогу, але для мене це більше схоже на мікроуправління, ніж на фактичну потребу.
Хуберт Каріо

@HubertKario - це викликає питання "Чи повинні ваші найкращі програмісти витрачати свій час, перевіряючи код інших людей?" Власне, мене так зацікавила відповідь на це питання, що я розмістив її тут: programmers.stackexchange.com/questions/181817/…
GlenPeterson

5

Швидкість. Іноді потрібно клонувати 10 чи 15 хвилин, щоб клонувати великий сховище git, тоді як сховище субверсії подібного розміру займає пару хвилин, щоб перевірити його.


6
Але замовлення / клонування - це рідкісна операція. У більшості сценаріїв git швидше, ніж підрив.
rds

5
git clone --depth=1твій друг, якщо тебе не цікавить історія
Hubert Kario

4

Я публікую це як відповідь, а не коментар.

Я визнаю, ніж DVCS зараз досить в тренді, але я спробую розповісти, чому.

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

Однак не кожен програмний проект настільки гарний, як він отримує:

  • Довгостроковий проект отримав велику користь від DVCS, оскільки він використовує менше накладних витрат, дозволяє набагато краще керувати (розгалуження тощо) та чудово підтримується такими хостами, як код Google і github.

  • Ці проекти не єдині, є й інші види проектів, які розробляються в компаніях без допомоги зовнішнього світу чи Інтернету: все робиться всередині, і часто на короткий термін. Хороший приклад: відеоігра. Код швидко розвивається.

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

  • У розробників є машини, які належать компанії, і це може швидко змінитися. Налаштування РЕПО - це втрата часу.
  • Якщо у цих хлопців немає власної машини, вони рідше працюють над тим самим вихідним кодом / частиною проекту. Плюс один для централізованих даних.
  • швидкість роботи мережі та великі гроші дозволяють використовувати централізований сервер, який працює з усім SVN, це погана практика, але створюються резервні копії тощо.
  • SVN просто простіший у використанні, навіть якщо це неправильний спосіб: синхронізація файлів на однолітках без надмірності не є простою проблемою, і "зробити це правильно" просто не вдається зробити це вчасно, якщо ви завжди хочете, щоб він був ідеальним.

Подумайте про машину ігрової індустрії та про те, як SVN - це економія часу; люди набагато більше спілкуються з цими проектами, тому що ігри стосуються багаторазового програмування та адаптивного коду: кодувати нічого важко, але це потрібно зробити правильно, як можна швидше. Наймаються програмісти, вони кодують свою частину, складають її, тестують її трохи, фіксують, роблять, тестери ігор будуть мати справу з рештою.

DVCS створені для Інтернету та для дуже складного проекту. SVN - це невеликі, короткострокові, тісні командні проекти. Вам не потрібно багато вчитися з SVN, це майже FTP з тупою різницею.


Чи можете ви пояснити приклад ігрової індустрії?
Джонні

3

Subversion і Git заохочують певні (і дуже різні) підходи до розвитку та співпраці. Деякі організації отримають більше від Git, а інші отримають більше від Subversion, залежно від їх організації та культури.

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

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

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

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

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

Нарешті, я також вважаю, що функціонування спільного використання за допомогою «гарячої» розробки бібліотеки під Svn (з використанням CI та тестово-орієнтованого підходу) дозволяє досягти темпів скоординованого розвитку, які важко досягти з більш розповсюдженою та слабко пов'язаною командою.


2

Нижче наведено дві причини, що я все ще залишаюсь у SVN.

  1. Крива навчання. SVN простіший ніж Git, навіть налаштування (сервер чи клієнт теж), зручність використання та команди.
  2. Кращі серверні пакети, такі як Subversion Edge , VisualSVN , uberSVN тощо.

1
+1 для №1. Порівняйте діаграми SVN та GIT тут steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git
s_t_e_v_e

1

Зараз у контролі версій є дві основні тенденції; Розподіл та інтеграція .

Git чудово підходить до децентралізації.

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

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


-1

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

Редагування повідомлень журналу після факту часто дуже корисно. Окрім того, що виправити помилку чи пропуск у повідомленні журналу, це дає змогу виконувати такі дії, як оновлення повідомлення журналу, щоб посилатися на майбутній фіксатор (наприклад, перегляд, який виправляє помилку або завершує роботу, внесену в поточній редакції) .

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


1
це також просто робити в git; наприклад, git --менд; Інший спосіб зробити це через скидання git --soft HEAD ^, яка просто повертається назад, але не змінює індекс, і таким чином ви можете редагувати / повторно писати повідомлення про фіксацію.
дог

Привіт, Дуг. Так, ви можете зробити це для вашого локального сховища, але я говорю про те, як тільки ви перенесли цю зміну в інше місце - "git commit --amend" вам не дуже допомагає. У SVN ви можете редагувати повідомлення журналу на центральному сервері саме тому, що існує концепція центрального сервера. Це я мав на увазі під «неможливим дизайном у децентралізованих системах». Я відредагую свою відповідь, щоб зробити це зрозумілішим.
Карл Фогель

1
Мені подобається, як "ніби можна поспілкуватися з історією" - це нібито особливість . Я вважав би це помилкою, якби це не було навмисно.
cHao
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.