Доступно багато систем управління версіями, включаючи такі з відкритим кодом, як Subversion , Git та Mercurial , а також комерційні, такі як Perforce .

Наскільки добре вони підтримують процес розвитку гри? Які проблеми з використанням VCS щодо нетекстових файлів (бінарних файлів), великих проектів тощо? Які рішення цих проблем, якщо такі є?

Для організації відповідей давайте спробуємо на основі пакета. Оновіть кожен пакунок / відповідь своїми результатами.

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

Оновлення : Знайдено приємну статтю, де порівнюються два VCS нижче - мабуть, Git - це MacGyver, а Mercurial - Bond . Ну, я радий, що це врегульовано ... А в автора є приємна цитата наприкінці:

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

Тим більше , що справжнім ворогом Гіта та Меркуріала є Субверсія . Данг, це світ з кодовим набором кодів , там, у FOSS-землі ...

Git

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

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

За допомогою SVN вам потрібен доступ до репортажу, щоб здійснити фіксацію. Що робити, якщо ви в дорозі чи в кафе, де немає інтернету? Не добре.

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

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

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

Якщо вам все ще цікаво про GIT, перегляньте http://thkoch2001.github.io/whygitisbetter/, щоб отримати добру інформацію / показники. Також перевірте див. Https://git.wiki.kernel.org/index.php/GitSvnComparsion

Меркуріал

Ключові риси:

• Розподілений VCS
• Безкоштовно, з відкритим кодом
• Сценарії плагінів легко писати --- можуть бути написані в Python або як сценарії оболонки
• Є безліч скриптів плагінів, які вже є у вільному доступі
• Багато доступної документації, включаючи цю книгу (настійно рекомендується)

Що стосується використання нетекстових файлів, останні версії Mercurial (> = 2.0) надають розширення для великих файлів за замовчуванням :

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

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

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

Джоел Спольський написав міні-підручник з використання Mercurial at Subversion Re-Education

Перфорс

Виконання сили (комерційний / закритий, централізований) - галузевий стандарт з ряду причин.

1. Це комерційний продукт, а це означає, що він постачається з комерційною підтримкою. Проекти з відкритим кодом можуть мати право на безкоштовну ліцензію (за вирахуванням технічної підтримки).
2. Він дуже добре підтримує робочі простори , що дозволяє дуже гнучкі макети джерел та ресурсів.
3. Він дуже добре підтримує списки змін .
4. Ви можете бачити, хто над чим працює. Ігри мають аномально велику кількість швидко змінюються бінарних файлів (активів) порівняно з іншими проектами розвитку. Більшу частину часу вони не підлягають зливанню, тому слідкуйте за тим, хто має що / де / коли є критичним. Клієнти Subversion і DSCC навмисно уникають цієї методики, але це досить вигідно в певних додатках.
5. Він підтримує гігантські коди / бази активів. Він не зберігає дублікати даних на клієнтських машинах, що важливо, коли ваш підвид дерева - це кілька десятків концертів.

При цьому, майже щодня очевидно, що Perforce не відчуває, що їх позиція в цій галузі загрожує. Їх візуальні інструменти, включаючи P4V та P4SCC (інтегруються з Visual Studio), є повільними та гнучкими, останні відомі, що заморожують Visual Studio для повного задоволення від цього. AnkhSVN знаходиться на відстані миль від Перфорса.

Коментар xan: Однак варто відзначити, що їх інструмент злиття, P4Merge (використовується для розмежування та злиття), є чудовим та набагато перевершує аналогічні Tortoise Merge. Дивно, але цей компонент доступний безкоштовно в рамках пакету P4 Visual Tools.

Коментар slicedlime: Ще одним недоліком Perforce є те, що розгалуження в ньому, як правило, є величезним болем, особливо якщо у вас великі дерева. Практично кожен інший ПК краще розгалужувати та зливати. Зазвичай це невелика ціна, щоб оплатити вищеперелічені переваги.

Коментар roe: Perforce надзвичайно балакучий. Без залучення сервера не багато чого. Найголовніше, що вам потрібен сервер для того, щоб зробити відкритий для редагування, а це означає, що вам потрібно перейти через кілька обручів, якщо ви збираєтесь перервати з'єднання з сервером.

Коментар jrista: Як щоденний користувач Perforce вже понад два роки, з розширеною розробкою та якісною інженерною командою понад 100 людей, я ознайомився з ним. Хоча це гідна система управління джерелами, але вона має свої недоліки, про які слід знати, хто оцінює системи SCC:

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

Підрив

• Відкритий, централізований

• Файли блендерів - я не зовсім впевнений, чи .blend файли є двійковими (вони виглядають так), але у мене не було проблем з їх додаванням до Subversion. Зробивши кілька експериментів, збільшення розміру файлу для змінених файлів здається номінальним, тому копіювати його не потрібно у весь файл.

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

• Дубльовані дані про клієнта - Subversion зберігає копію кожного копію кожного файлу в робочій області користувача як незайману копію. Перевагою цього є те, що ви можете зробити різницю або повернути, не повертаючись до сервера. Недоліком є ​​те, що ваші 10 гіг робочих файлів займають 20 гіг місця на диску.

• Список ігнорування - це властивість каталогу (простий з gui, дратує в командному рядку).

• Subversion дозволяє блокувати файли / об’єкти - що дуже корисно, якщо над одними і тими ж файлами працюють кілька виконавців та дизайнерів.

• Зовнішні фахівці - це чудовий спосіб керувати спільним (наприклад, бібліотекою чи базовим) кодом між проектами.

AlienBrain

Від Avid :

Alienbrain - це система управління цифровими активами для художників індустрії розваг

• Комерційний (дорожчий за Perforce), централізований
• Призначений для інтеграції з іншими професійними інструментами робочого процесу 2D та 3D, такими як Photoshop, Maya, 3ds Max, Microsoft Visual Studio тощо.

Я не маю досвіду роботи з AlienBrain, і про це чув лише з книги « Кодування гри, завершеної Майком МакШафрі». Однак, здається, він дуже думає про це:

Художники та інші учасники фактично використовуватимуть цей продукт, на відміну від інших, які в основному розроблені для того, щоб добре інтегруватися з Visual Studio, а не творчими програмами, такими як Photoshop та 3D Studio Max. Одним із великих недоліків інших продуктів є їх досить наївне поводження з нетекстовими файлами. AlienBrain був написаний з урахуванням цих файлів.

Звичайно, він також описує це як:

Для тих, хто має справді серйозні проблеми з відстеженням активів і не менш серйозними бюджетами ...

Team Foundation Server

від Microsoft

• Комерційний
• Централізований
• Дуже добре інтегрується з Visual Studio
• Гарна інтеграція Windows Explorer для користувачів, які не VS (тобто художників)
• Підтримує набори змін "Shelved", що є дещо аналогічним "схованню" в git, але це підходить до сервера; ви також можете оприлюднити ці полиці, щоб дозволити іншим користувачам інтегрувати їх для вас.
• Починаючи з 2012 року, він має дуже хороші робочі процеси з перегляду коду, вбудовані безпосередньо у Visual Studio
• Остання версія інструменту злиття дуже приємна. Авто злиття працює досить добре.
• Підтримує великі та обов'язкові файли просто добре (очевидно, ви не можете їх об'єднати)
• Дуже хороший сервер побудови
• Підтримує закриті реєстраційні реєстрації, які дозволяють оцінювати якість набору полиць (за допомогою автоматизованих збірок, тестів одиниць, аналізу коду) до того, як вона буде передана в сховище.
• Дуже хороші інструменти управління проектами (не суворо функції керування джерелами, але дуже корисні), що дають можливість простежувати від вимог високого рівня аж до коду.

Я широко використовував TFS для проектів симуляторів MILSPEC, і це досить добре. Напевно, не найбільше, якщо ти на Mac, хоча плагін затемнення в ці дні є. Версія, розміщена у хмарі, підтримує сховища git для бек-енд-файлу управління.

Він безкоштовний для до п'яти користувачів на Visual Studio Online (дозволяє закрити джерело; без обмежень розміру сховища), де він розміщений у хмарі. Якщо ви хочете розмістити його на місцях, це може бути дорого.

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