Я намагаюся зрозуміти переваги розподіленої системи управління версіями (DVCS).

Я знайшов Subversion перенавчання і цю статтю на Мартіна Фаулера дуже корисним.

Mercurial та інші DVCS просувають новий спосіб роботи над кодом із наборами змін та місцевими комісіями. Це не дозволяє об'єднати пекло та інші проблеми співпраці

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

Mercurial дозволяє мати лейтенантів

Я розумію, що це може бути корисно для таких великих проектів, як Linux, але я не бачу цінності в малих та дуже спільних командах (від 5 до 7 осіб).

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

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

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

ОНОВЛЕННЯ (12 січня) : Я зараз переконаний, що варто спробувати.

ОНОВЛЕННЯ (12 червня) : Я поцілував Меркуріал і мені це сподобалось. Смак його вишневих місцевих зобов'язань. Я поцілував Меркуріал лише щоб спробувати. Я сподіваюся, що мій сервер SVN це не проти. Це почувалося так неправильно. Це було так правильно. Не означає, що я закоханий сьогодні ввечері .

ЗАКЛІННЕ ОНОВЛЕННЯ (29 липня) : Я мав честь переглянути наступну книгу Еріка Сінка під назвою " Управління версіями за прикладом" . Він закінчив мене переконувати. Я піду на Меркуріал.

Примітка. Для відповіді на поточне запитання див. "Редагування"

Перш за все, прочитайте реверсію Subversion Джоела Спольського. Я думаю, що більшість ваших запитань там відповідуть.

Ще одна рекомендація - розмова Лінуса Торвальда на Git: http://www.youtube.com/watch?v=4XpnKHJAok8 . Цей інший також може відповісти на більшість ваших запитань, і це дуже цікаво.

До речі, щось мені здається досить смішним: навіть Брайан Фітцпатрік та Бен Коллінз-Суссман, два оригінальних творців підриву, в одному з розмов Google сказали, що "вибачте за це", посилаючись на те, що субверсія поступається меркуріальній (і DVCS взагалі).

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

• Ви не залежите від сервера та з'єднання, тобто швидші часи.
• Не будучи рабом у місцях, де можна отримати доступ до Інтернету (або VPN) лише для того, щоб мати змогу скористатися.
• У кожного є резервна копія всього (файлів, історії), а не лише сервера. Це означає, що кожен може стати сервером .
• Ви можете робити примусово, якщо вам потрібно, не псуючи інший код . Коміти місцеві. Ви не наступаєте один на одного пальцями ніг під час вчинення. Ви не руйнуєте чужі конструкції чи оточення лише виконуючи обов'язки.
• Люди, які не мають "доступу на доступ", можуть взяти на себе зобов’язання (оскільки обмін інформацією в DVCS не передбачає завантаження коду), знизивши бар'єр для внесків, ви можете вирішити, чи не змінювати їх як зміни.
• Це може посилити природну комунікацію, оскільки DVCS робить це важливим ... в підриві, те, що ви натомість, здійснюєте гонки, які змушують спілкуватися, але заважаючи вашій роботі.
• Дописувачі можуть об'єднатися та вирішити свої злиття, що означає менше роботи інтеграторів.
• Співробітники можуть мати свої відділення, не зачіпаючи інших людей (але при необхідності мати можливість ділитися ними).

Про ваші бали:

• Пекло злиття не існує в DVCSland; не потрібно обробляти. Дивіться наступний пункт .
• У DVCS кожен представляє "гілку", тобто є злиття щоразу, коли зміни витягуються. Названі гілки - інша річ.
• Ви можете продовжувати використовувати безперервну інтеграцію, якщо хочете. Не обов'язково IMHO, чому додавати складність? Просто продовжуйте тестування як частину своєї культури / політики.
• Меркуріал швидше в одних речах, git - швидше в інших. Не дуже до DVCS загалом, але до їх конкретної реалізації AFAIK.
• Кожен завжди матиме повний проект, не лише ви. Розподілена річ пов'язана з тим, що ви можете здійснювати / оновлювати локально, обмін / виведення з-за комп'ютера називається натисканням / витягуванням.
• Знову читайте Subversion Re-Education. DVCS простіші та природніші, але вони різні, не намагайтеся думати, що cvs / svn === база всіх версій.

Я надавав деяку документацію до проекту Joomla, щоб допомогти проповідувати міграцію до DVCS, і тут я створив кілька діаграм, щоб проілюструвати централізований vs розподілений.

Централізований

Поширений у загальній практиці

Поширений в повній мірі

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

Тепер це типовий робочий процес для проектів з відкритим кодом (наприклад, проект з широкою співпрацею) з використанням DVCS:

Bitbucket.org є дещо еквівалентом github для mercurial, знайте, що вони мають необмежену кількість приватних сховищ з необмеженим простором, якщо ваша команда менше п'яти, ви можете користуватися нею безкоштовно.

Найкращий спосіб переконатись у використанні DVCS - це випробувати DVCS, кожен досвідчений розробник DVCS, який використовує svn / cvs, скаже вам, що цього варто, і що вони не знають, як вижили весь свій час без цього.

EDIT : Щоб відповісти на вашу другу редакцію, я можу просто повторити, що з DVCS у вас є інший робочий процес, я б радив вам не шукати причин, щоб не спробувати це через кращі практики , це здається, коли люди стверджують, що OOP не є необхідні, оскільки вони можуть обійти складні дизайнерські зразки з тим, що вони завжди роблять з парадигмою XYZ; ви можете отримати вигоду в будь-якому випадку.

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

Щодо "злиття пекла", ви говорите "якщо ми не експериментуємо", я кажу "навіть якщо ви експериментуєте + maintaing + працюєте в оновленому v2.0 одночасно ". Як я вже говорив раніше, пекельне злиття не існує, оскільки:

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

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

Щодо роботи наборів змін та підвищення продуктивності. Я спробую проілюструвати це на прикладі, який я хотів би навести: проект mootools перемикається зі svn, проілюстрованого в їхньому графіку мережі github .

Раніше

Після

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

Моя рекомендація вам - шукати когось, хто знає, як використовувати mercurial / git, і сказати йому / їй, щоб він пояснив це вам рукою. Провівши близько півгодини з друзями в командному рядку, використовуючи mercurial з нашими настільними комп’ютерами та обліковими записами bitbucket, показуючи їм, як злитися, навіть створюючи конфлікти для них, щоб побачити, як виправити смішну кількість часу, я зміг показати їм справжня сила DVCS.

Нарешті, я б рекомендував вам використовувати mercurial + bitbucket замість git + github, якщо ви працюєте з Windows. Mercurial також є більш простим, але git є більш потужним для складнішого управління сховищами (наприклад, git rebase ).

Деякі додаткові рекомендовані читання:

• Розподілені системи контролю ревізії: Git vs. Mercurial vs. SVN
• Git vs. Mercurial: Будь ласка, розслабся
• Розподілений контроль над версіями та Git [частина 1] та розподілений контроль над версіями та Git [частина 2]
• Git / Mercurial vs. Subversion: Боріться!
• DVCS проти підривної дії, 3 раунд
• Чому мені подобається більше, ніж Git Mercurial ( частина 1 , частина 2 )
• Співпраця з Git: Зменшення тертя співпраці з відкритим кодом з Git VCS
• "Як DVCS працювали на вас досі?" - повідомлення на Joomla! Список розсилки Framework Development з проханням отримати зворотний зв'язок після експериментального прийняття меркуріалу і git для Joomla! Проект платформи
• Розгалуження DVCS (з Mercurial) - детальне та орієнтоване на приклад, як виглядає розгалуження у DVCS, що, можливо, є найважливішою особливістю у цих системах

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

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

DVCS - це Subversion, що Bittorrent - ftp

(технічно, не юридично). Можливо, якщо ви думаєте, що це закінчилося, ви можете зрозуміти, чому це такий великий стрибок уперед?

Для мене наш перехід на git одразу призвів до

• Наші резервні копії простіше зробити (просто "git віддалене оновлення", і ви закінчили)
• Простіше робити невеликі кроки під час роботи без доступу до центрального сховища. Ви просто працюєте та синхронізуєтесь, коли повернетесь до мережі, що розміщує центральний сховище.
• Швидше Гудсон будує. Набагато швидше використовувати git pull ніж оновлення.

Отже, подумайте, чому bittorrent кращий за ftp, і перегляньте свою позицію :)

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

Вбивча особливість розподілених систем управління версіями - розподілена частина. Ви не отримуєте "робочу копію" з сховища, ви клонуєте всю копію сховища. Це величезна кількість, оскільки дає потужні переваги:

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

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

Ви коли-небудь виправили помилку і виявились на кшталт:

r321 Fixed annoying bug.
r322 Argh, unexpected corner case to annoying bug in r321!
r323 Ok, really fixed corner case in r322
r324 Oops, forgot to remove some debugging code related to r321
...

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

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

r321 Fixed annoying bug.

Що саме так і має бути.

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

• Зробіть звичайний ванільний злиття . Приносить все в бородавки і все.

• Зробіть ребазу . Дозволяє перебирати історію філій, перевпорядковувати порядок комісій, викидати коміти, об’єднувати документи разом, переписувати повідомлення про фіксацію --- навіть редагувати комісії або додавати нові! Розподілена система контролю версій має глибоку підтримку перегляду коду.

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

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

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

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

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

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

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

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

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

І підрив має деякі недоліки. Наприклад, якщо ви перейменовуєте каталог на диску, він не перейменований у сховище. Переміщення файлів не підтримується, що робить переміщення файлу операцією копіювання / видалення, ускладнення змін, коли файли переміщені / перейменовані. І відстеження злиття насправді не вбудовується в систему, а реалізується у формі обходу.

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

З іншого боку, git не дозволяє вам розгалужуватись на окремих рівнях каталогів, як це робить субверсія.

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

Що стосується продуктивності, Git або будь-який інший DVCS має велику перевагу перед SVN, коли вам доведеться переходити з однієї гілки на іншу або переходити з однієї редакції на іншу. Оскільки все зберігається локально, все відбувається набагато швидше, ніж для SVN.

Це одне могло змусити мене переключитися!

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

git bisect (і всі його наслідки для вашого основного сховища)

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

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

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

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

Сторінка " gitworkflows man" - це гарне ознайомлення з робочими потоками, для яких Git розроблений. Також чому Git краще, ніж X, обговорює робочі процеси Git.

Великі, розподілені проекти

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

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

Чому б не використовувати їх у тандемі? У моєму поточному проекті ми змушені використовувати CVS. Однак ми також зберігаємо локальні сховища git для того, щоб робити особливості розвитку. Це найкраще з обох світів imo, оскільки ви можете спробувати різні рішення та зберігати версії того, над чим працюєте, на власній машині. Це дозволяє відкатати попередні версії функції або спробувати кілька підходів, не потрапляючи в проблеми, коли ви псуєте код. Наявність центрального сховища дає вам переваги мати централізоване сховище.

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

DVCS

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

CVCS

Робоча модель CVCS (зокрема Subversion) полягає в тому, що ви робите спільну розробку . Ви розробляєте свою нову функцію / виправлення в безпосередній співпраці з усіма іншими членами команди, і всі зміни одразу доступні для всіх.

Інші відмінності

Інші відмінності між svnта git/ hg, такими як версії та набори змін, є випадковими. Дуже добре можна створити DVCS на основі версій (як у Subversion) або CVCS на основі наборів змін (як у Git / Mercurial).

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

• Я не боюся перевіряти речі, так як у мене немає проблем з тим, щоб перевести його в неповний, але складений стан.
• Коли я пережив злиття-пекло, це було в ситуаціях, коли це сталося б svnі в git/ і / hg. Наприклад, V2 деякого програмного забезпечення підтримувала інша команда, використовуючи інший VCS, тоді як ми розробляли V3. Іноді помилки доведеться імпортувати з V2 VCS ​​до V3 VCS, що в основному означало робити дуже велику реєстрацію на V3 VCS (з усіма виправленнями в одному наборі змін). Я знаю, що це було не ідеально, але це було рішення управління використовувати різні системи VCS.