Просунуті методи підриву, що мені не вистачає?

10

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

Наприклад

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

version-control

— Дерек Адаїр
джерело

3

Ви можете розглянути можливість використання hg для своїх локальних відділень (ви можете використовувати його із svn просто чудово, перевірте це )

— OneOfOne

Га! Вам не вистачає меркуріалу.

— DexterW

3

"Advanced Subversion" звучить як оксиморон. Використовуйте Git або Mercurial, якщо тільки локально.

— Macneil

7

Щоб звернутися до свого прикладу, у вас є три можливості:

Ви можете зробити один файл. Якщо ви використовуєте IDE для доступу до сховища, він, швидше за все, має вигляд, щоб вибрати чи скасувати виділення окремих файлів перед тим, як зробити. У командному рядку ви вводите команду svn commit file1 path1/file2 path2file1, path1 / file2 та кожну зміну під path2.
Ви можете робити різні робочі копії. Ви працюєте над своєю великою функцією у стандартній робочій копії та отримуєте інформацію про нагальну помилку. Ви можете зарахувати своє сховище в інший каталог і виправити помилку у цій другій робочій копії. Ви навіть можете перевірити лише підкаталог з компонентом, де відбувається помилка. Після виправлення помилок ви можете скористатися у своїй другій робочій копії, не роблячи роботу над головною функцією. EDIT: Цей спосіб також описаний у відповіді Анни Лір.
Ви створюєте відділення для роботи над своєю функцією. Для цього ви використовуєте команду copy. Якщо ви використовуєте стандартний-макет для вашого сховища (каталоги з Projectname і підкаталоги з іменами хобот, теги і гілки, стовбур , що містить проект) , ви можете використовувати СВН-копіювати-команду як слід створити гілку: svn copy svn://hostname/projectname/trunk svn://hostname/branches/branch-for-feature-X. Тепер ви можете переключити свою робочу копію на нове місце: комутатор svn svn switch svn://hostname/projectname/branches/branch-for-feature-X. Якщо ви переходите в режим виправлення помилок, ви здійснюєте фактичні зміни, перемикайте робочу копію назад на стовбур, виправляйте помилку та фіксуйте і перемикайте робочу копію назад у свою гілку функцій. Якщо ви готові до розробки функції, ви можете об'єднати її назад до багажника.

Для простого описаного випадку ви зазвичай використовуєте №1 (я використовую найчастіше), іноді №2. Робота з гілками (справа №3) є більш складною ( читайте більше ), але дозволяє отримати більше хитрощів. Але гілки, що відповідають вашому опису підрепозиторію.

Крім вашого прикладу, я не можу сказати багато чого. Про Subversion є багато речей, але я не знаю, що ви вже використовуєте і що вам потрібно для вашого проекту. Щоб дізнатися більше про SVN, SVN-Book - це чудовий ресурс: http://svnbook.red-bean.com/

— Мнемент
джерело

3

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

— Стівен С. Сталь

7

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

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

D:\Dev\MajorFeature1
D:\Dev\Bug12345
D:\Dev\MajorFeature2

тощо.

Все це можна перевірити з одного місця у вашому SVN, наприклад http://mysvnrepo/trunk.

Таким чином, ви можете скористатись пісочницею виправлення помилок, не впливаючи на розробку функцій, хоча вам потрібно буде запустити svn updateз інших пісочниць, щоб отримати зміни, здійснені для виправлення помилки.

— Адам Лір
джерело

4

Ви взагалі дивились підрозділи Subversion ?

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

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

У ваших розробників може бути перевірено кілька робочих копій - магістраль та будь-які гілки - або можна змінити svn switchкоманду між стовбуром та певною гілкою за допомогою команди.

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

— JBRWilkinson
джерело

3

Поточний розмір моєї робочої копії - 10 ГБ, що містить понад 50 000 файлів. У мене може бути декілька примірників для різних галузей, але для створення нової копії потрібно трохи часу!

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

— Ксав'є Нодет
джерело