Які ваші улюблені системи управління версіями? [зачинено]


41

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

Отже, на вашу думку, найкраща система управління версіями?


1
en.wikipedia.org/wiki/Comppare_of_revision_control_software - це чудова таблиця порівняння саме для цього. Питання для обговорення ... Вікі спільноти?
Кріс,

4
Перший, хто публікує ім'я, отримує відповідь ... Це має бути вікі спільноти.
takehin


Не помітили, що це вже вікі спільноти .
приймає

Відповіді:


81

Меркуріал

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


Мені доведеться спробувати Mercurial деякий час, оскільки я вже спробував 2 великих 3. А оскільки Google Code підтримує це ...
TheLQ

2
Mercurial - це солодко, якщо ви використовуєте Netbeans. інтеграція IDE ідеальна.
Seun Osewa

4
Я віддаю перевагу Mercurial просто тому, що TortoiseHg зріліший за TortoiseGit :-) (весь досвід роботи в Windows набагато кращий і в Mercurial)
Дін Гардінг

+1, я пропоную зробити Mercurial сміливішим та більшим (як це зробив Гаурав у своїй відповіді)
Tim Post

Mercurial досить солодкий. Я та моя команда користуємось ним близько 2 місяців, і це подих свіжого повітря порівняно зі SVN.
Gary Willoughby

72

Git

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

Одне велике застереження для користувачів Windows: Інструменти Git для Windows, хоча і безумовно корисні, не дуже зручні. Коли я змушений був деякий час використовувати Windows, я спробував інтерфейс Windows Mercurial за допомогою інструменту інтеграції Hg-Git, щоб я міг використовувати свої сховища Git, і виявив, що набагато простіше у використанні.


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

1
@Khelben - У цьому є правда, так. Однак, як видається, найбільша кількість літератури / статей / навчальних посібників у мережі присвячена саме цьому. Я регулярно виявляю, що книги Git виходять, Mercurial - не так вже й багато (використовуючи тут Mercurial як контраст, оскільки він багато в чому схожий на Git). Не можу сказати, добре це чи погано, але, здається, люди це використовують.
Грак

2
msysgit можна використовувати під Windows.

1
Я припускаю, що git, Mercurial тощо - все добре, але я пішов на git здебільшого тому, що auf GitHub. GitHub почуває себе приємніше, ніж порівнянні сайти, і багато важливих проектів розміщуються там. GitHub значно знижує бар'єр, щоб значно сприяти відкритому коду.
LennyProgrammers

2
Меркуріал не потребує книги.
Warren P

24

Попередження: З цього посту я знайшов Меркуріал і люблю його набагато краще, ніж SVN. Тож ця публікація трохи застаріла з коментарями Pro SVN та загальними анти-DVCS, але анти-git-матеріали все ще актуальні


Я фанат SVN над Git.

Чому? Оскільки SVN було набагато простіше для одного розробника чи невеликої команди, а git (конкретно msysgit) залишив мене з неприємним смаком у роті.

Коли я стажувався в невеликому магазині, мене познайомили з Git на Windows. Я одразу помітив обсяг роботи, який потрібен, щоб він працював з Github. По-перше, мені довелося генерувати приватний ключ ssh, вставляти відкритий ключ у Github, потім відкривати конкурс і відкривати мій приватний ключ кожного разу, коли я хотів натиснути, що дуже дратувало.

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

Потім був заплутаний процес взяти на себе зобов’язання. TMK, я повинен був спочатку "поставити" всі файли, які я хотів зробити (які висмокталися, коли у вас було багато файлів; мені знадобилося деякий час, щоб знайти команду вручну, щоб все поставити), потім виконати фіксацію, а потім натиснути на головне репо (чому це окрема операція ?!).

У вас також були не (!) Дуже корисні дані про фіксацію. О, дивіться, це виконувати 14f74433245ae17aeeaa частина дерева 2167a4934d0a4a7db0de та батьківського d7042abb4821d3faf600. Чорт це означає? Я мав би змогу досить швидко розібратися з речами, і не потрібно звертатися до якоїсь дивної документації.

Якщо говорити про документацію, то, принаймні, коли я її використовував, здавалося, що все було у форматі файлів man linux man, IE для мене заплутано і марно. Я рідко міг знайти велику допомогу в документах і просто вдався до google.

І з комітами, одне, що мені не сподобалось, - це відсутність номерів версій. Тепер я знаю, що це пов’язано з дизайном git, але для будь-якого програмного забезпечення потрібен номер версії. Я все ще пам’ятаю маркери, які з'являлися б, сказавши «Змінено версію до 1.8.6» чи щось подібне, але ви все одно не можете створити числа. Мені версія версії 1.8.6.5164 (остання частина - номер редакції) говорить мені набагато більше, ніж просто 1.8.6 і примітка, що щось незначне змінилося, спробуйте

Отримуючи специфіку програмного забезпечення, базовою програмою для Windows є msysgit, що є жахливим інтерфейсом. Він кілька разів замикався на мені, мав жахливий інтерфейс, і інтеграція CLI-GUI була в кращому випадку нелегкою. Наркомани командного рядка навколо мене ще більше ненавидів гуї.


Тепер давайте подивимось на SVN. А оскільки я в Windows та маю обліковий запис google, зокрема TortoiseSVN та Google Code.

По-перше, повна інтеграція оболонки, щоб зробити все у сховищі (і для вас, Linux, люди RabbitVCS робить те саме), не потрібен основний графічний інтерфейс. Отримати сховище просто як замовлення, не потрібен SSH (не пам'ятаю, чи потрібен Github SSH для витягнення), і жодне ціле репо + всі минулі комісії не сидять на вашому HD.

Здійснення справи надзвичайно легко, головним чином тому, що не потрібно SSH або інсценування. Ви просто перевірте всі потрібні файли, використовуючи дуже корисну опцію, щоб вибрати всі параметри, які у моїй версії msysgit були недоступні, введіть повідомлення про фіксацію та натисніть покласти команду. Потім Код Google запитує вас про вашу логінну інформацію (яку зберігають більшість клієнтів) та завершене. Простий, легкий і без SSH

Номери версій? За допомогою простого коду ви можете додати номер версії та номер комісії до всіх замовлень, що значно спрощує ситуацію. Ви також отримуєте придатні номери версій, які фактично показують зміну, наприклад, 1.8.6.5165 новіший, ніж 1.8.6.5164.

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

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


Який я б рекомендував? Добре, що у великих команд git має свої переваги, головним чином у своєму нелінійному циклі розвитку. В іншому проекті я бачив, як 4 програмісти починають в окремих гілках, потім об'єднують весь код дуже дивними способами, які якимось чином перетворюються на остаточну гілку. У Github та msysgit був дуже приємний інструмент візуалізації для всього проекту, який мені дуже сподобався.

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


6
Злиття з SVN є досить ризикованим (порівняно з git). Це одне, що важливо відзначити при будь-якому порівнянні.
Хелбен

5
Чому потрібно кожного разу "підводити конкурс"? Це ключовий агент. Ви повинні піднести це лише один раз, коли ви увійдете на свою машину. Ви додаєте свій ключ, і все закінчено . (А ви можете зробити це ще простіше, пов’язавши ваш файл ключів із виступів і додавши його до вашої запускової папки. Увійдіть, він з'явиться у діалоговому вікні, що підкаже вам про вашу парольну фразу.)
Frank Shearar

3
@Thorbjoern @Frank Shearer: Думаю, сам факт, що ви говорите: "ти можеш це зробити, або ти можеш це зробити, а не мати цих питань", підкреслює те, що це рішення проблеми чи проблеми. Це не проблема з деякими іншими VCS '.
Стівен Еверс

4
Ця відповідь вражає мене як багато нарікань і стогонів на щось, на що плакат явно не потребував часу, щоб зрозуміти. Я багато часу проводив і в git і svn, і в Linux і Windows, і свідчить про те, що git значно перевершує svn, в концепції, моделі даних, зрозумілості та корисності.
gahooa

4
@ TheLQ Ні. Це зовсім не "ваш менталітет Linux". Це легко налаштувати, це добре документально підтверджено, PuTTY - це чудовий набір програм для Windows, який робить речі справді дуже простими у використанні. І вам справді слід шифрувати передачу коду, якщо ви працюєте через будь-яку загальнодоступну мережу. І для користувачів Windows образливо вважати, що вони занадто дурні, щоб навчитися користуватися інструментами, якими вони повинні користуватися. Я не прошу людей вкладатися в речі. Я прошу їх зашифрувати важливу інформацію.
Френк Шірар

22

Наступна цитата Q4TD майже все це підсумовує для мене:

«Я любив Гіта, поки не спробував. Тепер я люблю Меркуріал ».

        - Тор Норбі, подкаст Java Posse

Крім того, hgsubversion робить досить хорошим клієнтом підриву для Linux (де я зазвичай використовую командний рядок, на відміну від Windows, де я зазвичай використовую TortoiseSVN). Найбільша перевага: відсутність .svnпідпапок у кожній папці, лише .hgна верхньому рівні.

Оновлення: У відповідь на прохання Алекса в коментарях "сказати більше про те, чому git не працює для вас і як Mercurial працював краще":

Я б не сказав, що Git не працює для мене, але Murcurial працює краще IMO.

Якщо коротко, це Mercurial:

alt текст

і це Git:

alt текст

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

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

Ба, тепер подивіться, що ви зробили? Повсякчас гнітують. Рухайтеся, нічого не бачити ... нічого не бачити ...

Оновлення 2: І ще один привітний твіт, який я щойно натрапив:

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


Ви коли-небудь пробували RabbitVCS?
TheLQ

Ні, але я використовую KDE, а не Gnome, щоб він мені не підходив. Я періодично використовую графічний клієнт SVN в Linux, але тільки справді, коли роблю щось трохи езотеричне, наприклад, досліджуючи сховище або порівнюючи попередні версії. Не для простого додавання / видалення / фіксації / журналу. Командний рядок швидше.
Еван

2
Не могли б ви сказати більше про те, чому git не працював для вас і як Mercurial працював краще? Це було б досить цікаво читати.
Олексій Фейнман

Я впевнений, що в зображенні Git не вистачає 6-дюймової прямої бритви ...
Tim Post

2
@Tim: rebase? Це, мабуть, з іншого боку.
Алан Пірс

14

У мене немає єдиної "найкращої" системи управління версіями, а скоріше однієї найкращої парадигми VCS.

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

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


3
Це чудова відповідь. Немає жодної "найкращої" системи VCS, але я повністю погоджуюсь, що слід використовувати DVCS.
Нік Ходжес

Зробіть мій DVCS, але тримайте, будь ласка, гомеоморфні ендофайнери, які відображають підскладки гільбертового простору. Ерго, Меркуріал.
Warren P

11

Не можу сказати, що я стикався з найкращим програмним забезпеченням для контролю версій, але можу сказати вам триматися подалі від VSS та MKS. Обидва - собаки, яких слід уникати будь-якою ціною.


7

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

Fossil - це розподілений варіант управління версіями, відстеження помилок та wiki-проект, побудований на базі даних SQLite як сховище.


5

Team Foundation Server

Оскільки:

  1. Це хороший, міцний VCS . (Я б не вважав це найкращим в будь-якому випадку, але він має приємні додаткові послуги.)
  2. Вбудована функція відстеження завдань та помилок, які інтегруються у Visual Studio, допомагає мені зосередитись та знати, над чим мені потрібно працювати над усім в одному місці (автоматично застосувати реєстрацію до помилки чи завдання та закрити її досить добре, хоча ви можете отримати плагіни для інших систем / eclipse / тощо для цього.)
  3. Він інтегрує завдання / відслідковування помилок / проекти безпосередньо в Project Server, тому мені рідко доводиться постійно оновлювати плани та графіки проекту. Оновлення до проекту на сервері проекту автоматично фільтруються як завдання в TFS і в Visual Studio, щоб я бачив автоматично.

2
Мені цікаво, як ви відчували, що ваш робочий процес обмежується виключно Visual Studio для майже всієї роботи з розробки. Крім того, чи доводилося вам робити якісь налаштування інфраструктури для TFS? Мій досвід таким чином був протилежним вашому: №1 - VCS не був простий у використанні, часто був лускатим, а режим офлайн створив сам сатана. №2 Вбудоване відстеження завдань та помилок було громіздким порівняно з іншими інструментами, тому №3 для нас не було важливим і створювало дублювання роботи. Я використовував це вже 3 різні часи з однаковими поганими результатами щоразу.
Йордан

1. Я погоджуюся з смоктанням режиму офлайн. У мене не було взагалі багато проблем в Інтернеті, але я завжди зв’язаний. Багато елементів управління VCS, особливо при перезаписі папок, насправді приховано глибоко в меню. Це проблема у вас? 2. Це, безумовно, громіздкіше, але економить загальну роботу для моєї команди, інтегрованої із сервером Project. 3. Як створюється дублікат роботи? Ви дублюєте завдання на сервері проекту та TFS? Існує плагін з відкритим кодом для 2007 року та бета-версія для 2010 року, яка дозволяє синхронізувати один з одним.
Райан Хейс

1
Це обмежило мене на VS, але ми повністю магазин .NET. Однак я використовую TFS разом із своїми проектами Java вдома. Спробуйте SVNBridge на сайті svnbridge.codeplex.com, який дозволяє використовувати Черепаху разом із TFS. Якщо ви використовуєте черепаху (як і більшість людей на Java, рубіні, не -.net), це допоможе вам у процесі роботи в інших проектах.
Райан Хейс

4

Я використовував безліч систем управління версіями за свою довгу історію:

  • RPPT - (рулони перфорованої стрічки паперу). У взуттєвій коробці. Я не жартую.
  • PVCS - (система управління версією Polytron). Перший справжній VCS я використав.
  • SCCS - так давно я не пам’ятаю жодної речі, яка була надзвичайно хорошою чи поганою.
  • RCS - як інші зазначали, скоріше смоктав би спітнілі ослінні кульки.
  • CVS - це був лише біль при використанні з більш ніж двома програмістами. найкраща особливість: rcs2cvs.
  • VSS - він працює, за винятком вівторка, коли він псує все ваше сховище.
  • Perforce - коштує дорожче, ніж моя машина. Сам VCS є прийнятним, але хлопець ІТ-хлопців, які контролюють кожен аспект його використання, ніколи не викладе його у мій "бажаний" список.
  • SVN - розгалуження і злиття - це сука, але в цілому це краще, ніж будь-який з попередніх. Не так добре, з великою кількістю крихітних непересічних змін, які очікують на перегляд.
  • Меркуріал - який невеликий досвід я маю з цим, мені подобається. Я можу спробувати це на своєму наступному проекті.
  • Git - ніколи не було можливості ним користуватися.

Хоча пара була жахом, більшість були "штрафом". Вони не заважали мені. Поки інструмент не ускладнює моє життя , я не дуже проти.

Справжня річ - зрозуміти сильні та слабкі сторони кожного. Розуміння цільового середовища:

  • розповсюджені або локальні
  • невелика команда чи велика
  • розміщена служба vcs чи ні
  • проста інтеграція в інші інструменти

Джоел також вийшов з важливим спостереженням: Дізнайтеся про інструмент та його справжню модель використання. Він з усіх сил намагався змусити Меркуріал поводитись як Підрив.


1
Якби тільки коментар до VSS був жартом ... уникай, як чуми.
DevSolo

Ах, PVCS, спогади, які повертає :) Який шматок сміття був.
Генрі

Цей список нагадав мені мову, засновану на «стрілянині в ногу». +1
Включення

Я пам’ятаю погані речі про SCCS, але це було загалом корисно. Я пам’ятаю, що намагався одночасно працювати над файлами з SCCS та іншими програмістами, і тому я закохався в CVS, коли побачив це.
Девід Торнлі

Visual SourceSafe, VCS, спеціально для програмістів, які хочуть розвести очі ложками.
Марк Бут

2

Однією з новіших систем, які ми використовуємо в моєму офісі, є Plastic SCM (http://www.plasticscm.com/). Це дуже добре працює для нашої невеликої команди та дає нам чудовий контроль над кожним аспектом управління джерелами.


1

SCCS .

Або, якщо у вас не трапляється печера останні 38 років, CSSC .

Серйозно, моя компанія використовує TeamWare , який є своєрідною псевдо DVCS на основі SCCS.

Ні, я не жартую.

Sun переключилася на команду TeamWare лише кілька років тому. Тепер ви повинні зрозуміти, чому, здавалося, Java рухається так повільно.


1

MPW: Ну, я не можу насправді дати йому огляд, незважаючи на свої зусилля.

Це було ще тоді, коли я вивчав програмування у середній школі, і єдиний справді безкоштовний компілятор C ++, який мав, був Macintosh Programming Workbench, який я тримав на блискавковому диску і вискакував у будь-який клас Performa, який був доступний у лабораторії.

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

Це була моя перша кисть з VC, і остання на довгий час. Зараз я використовую git для всього.


Проектор! Під час роботи за сумісництвом під час коледжу я використав (виправдану) версію цього. Хороші часи.
RyanWilcox

0

RCS - система контролю ревізії

Індивідуальне кодування зроблено так просто.


Ви жартуєте, правда Ксепох? Будь ласка, жартуй.
Marc W

Ви, хлопці, змушуєте мене сміятися. Насправді я використовую RCS, але ТОЛЬКО для моїх особистих веб-сайтів, & c. Я наполовину жартував використовувати його для великих розробок, Але я бачив, що він використовувався виключно (а не CVS) для спільних систем Unix для розробки. Чесно кажучи, у нас з цим взагалі не було проблем, але НЕ піддається будь-чому, окрім однієї функції сервера.
Черга Jé

1
@Xepoch, вам може бути краще вивчити Git або Mercurial- DCVS чудово підходить для сольного розвитку.
Рибний прикорм

1
Ви знаєте, що насправді приємна річ у RCS? Ви можете помістити всі свої RCS, v файли у відповідну структуру каталогу, і у вас сховище CVS майже готове до роботи. Тоді є достатньо інструментів для перетворення CVS в будь-яку сучасну систему, яка вам подобається, наприклад, Mercurial.
Девід Торнлі

@Xepoch, простота резервного копіювання розподілених vcs'es неперевершена.

0

Не ClearCase, принаймні для системи Unix / Linux (можливо, з Windows інсталятор простіше). Мені було легше вивчити новий інструмент, Perforce, ніж оновити наш сервер ClearCase.

В даний час я використовую Perforce на роботі, і мені це подобається, але я поняття не маю, чи найкраще це. Налаштування середовища командного рядка та сервера Perforce трохи незручно, але використовувати Visual Client досить просто. Мені подобається думати, що користувачі мають досить легкий час з цим для щоденних завдань; це лише початкова настройка потребує певної роботи.


0

Я використовував Visual SourceSafe і ненавидів його, але це було краще, ніж нічого, але не набагато. Останні кілька років використовував щось написане Qumasoft.com, написане QCVS, власником і підтримкою якого є програміст Джим Воріс. Простий gui, дешева ціна, хороша підтримка.

Просто виконує роботу.

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