SVN: головные боли ответвления Выпуска, как объединиться в изменениях веб-сайта как и при очистке для движения живой?

Обычно люди, как и вы, разрабатывают транк, и в какой-то момент решают выпустить релиз, создавая ветвление с именем «release_something». Это не постоянный процесс максимального объединения вещей в выпуске, а скорее процесс тегов и замораживания :-). Тогда работа, проделанная над выпускной веткой, будет состоять в основном из исправлений ошибок, которые как можно скорее будут объединены в основной ветке: с таким процессом это намного проще.

Судя по тому, чего вы хотите достичь, кажется, что вы правы: лучшим решением было бы иметь одну ветку для каждой функции, а затем объединять их одну за другой в магистрали и выборочно в ветке выпуска. Subversion не кажется лучшим инструментом для такого рода разработки.Если вы используете DVCS, например hg или git, у вас может быть один репозиторий для каждого разработчика, попросите их как можно скорее объединить / отправить свои наборы изменений в магистраль, чтобы протестировать максимум функций, интегрированных вместе, и найти потенциальные проблемы. . Но у вас также будет другой репозиторий, называемый «релиз», который будет поддерживать только один человек, который будет выборочно извлекать такую-то функцию / патч из репозиториев ваших разработчиков. В hg, например, который я знаю лучше, когда вы извлекаете изменения, которые еще не были объединены (например, из репозитория разработчика в репозиторий выпуска), создаются несколько «голов», то есть какие-то анонимные ветки, и вы может решить изменение за изменением, функция за функцией, если вы хотите объединить эти «головы» в основную ветку не.

Я считаю, что благодаря этой гибкости и поскольку инструменты DVCS могут обрабатывать ветки и слияния намного лучше, чем централизованные инструменты, они будут намного лучше соответствовать вашим потребностям.

Надеюсь, это поможет.

Ура,
Кристоф.

= Они всегда говорят, что время меняет вещи, но на самом деле вам нужно =
= изменить их самостоятельно. --Энди Уорхол =

Давайте попробуем описанный вами сценарий и посмотрим, что происходит на самом деле (я использую командную строку по очевидным причинам, но она работает точно так же в TortoiseSVN ):

# let's create a simple repository for testing and add some baseline data:
$ svnadmin create test

$ svn import baseline file:///path/to/repo/test/trunk -m "Import baseline"
Adding         baseline/other.txt
Adding         baseline/css.txt

Committed revision 1.

# now create a branch:
$ svn copy file:///path/to/repo/test/trunk file:///path/to/repo/test/branches/r1 -m "branched" --parents

Committed revision 2.

# Pete changes some CSS to make a new button look pretty (Revision 3)
$ svn co file:///path/to/repo/test/trunk Pete-trunk
A    Pete-trunk/other.txt
A    Pete-trunk/css.txt
Checked out revision 2.
$ svn diff Pete-trunk/
Index: Pete-trunk/css.txt
===================================================================
--- Pete-trunk/css.txt  (revision 2)
+++ Pete-trunk/css.txt  (working copy)
@@ -1,3 +1,3 @@
 This is a test
-more lines
+more lines Pete's change
 even more
$ svn commit Pete-trunk/ -m "Pete's first change"
Sending        Pete-trunk/css.txt
Transmitting file data .
Committed revision 3.

# meanwhile, Dave add some CSS to the bottom of the same CSS file as Pete's for a new feature (Revision 4)
$ svn co file:///path/to/repo/test/trunk Dave-trunk
A    Dave-trunk/other.txt
A    Dave-trunk/css.txt
Checked out revision 3.
$ svn diff Dave-trunk/Index: Dave-trunk/css.txt
===================================================================
--- Dave-trunk/css.txt  (revision 3)
+++ Dave-trunk/css.txt  (working copy)
@@ -1,3 +1,4 @@
 This is a test
 more lines Pete's change
 even more
+Dave's change
$ svn commit Dave-trunk/ -m "Dave's change"Sending        Dave-trunk/css.txt
Transmitting file data .
Committed revision 4.

# Dave's mod gets the nod so he merges it into Release and commits it (Revision 5)...
$ svn co file:///path/to/repo/test/branches/r1 Dave-branch
A    Dave-branch/other.txt
A    Dave-branch/css.txt
Checked out revision 4.
$ svn merge -c4 file:///path/to/repo/test/trunk Dave-branch
--- Merging r4 into 'Dave-branch':
U    Dave-branch/css.txt
$ svn diff Dave-branch/

Property changes on: Dave-branch
___________________________________________________________________
Added: svn:mergeinfo
   Merged /trunk:r4

Index: Dave-branch/css.txt
===================================================================
--- Dave-branch/css.txt (revision 4)
+++ Dave-branch/css.txt (working copy)
@@ -1,3 +1,4 @@
 This is a test
 more lines
 even more
+Dave's change
$ svn commit Dave-branch/ -m "Merged Dave's change to release"
Sending        Dave-branch
Sending        Dave-branch/css.txt
Transmitting file data .
Committed revision 5.

# Pete adds more buttons to finish this mod, no CSS changes here though (Revision 6)
$ svn diff Pete-trunk/Index: Pete-trunk/other.txt
===================================================================
--- Pete-trunk/other.txt    (revision 2)
+++ Pete-trunk/other.txt    (working copy)
@@ -1 +1,2 @@
-another file
\ No newline at end of file
+another file
+Unrelated change
\ No newline at end of file
$ svn commit Pete-trunk/ -m "Pete's second change"Sending        Pete-trunk/other.txt
Transmitting file data .
Committed revision 6.

# Pete then merges his mods (Revision 3 and 6) into the Head of Release (which has Daves merge in it)
$ svn co file:///path/to/repo/test/branches/r1 Pete-branch
A    Pete-branch/other.txt
A    Pete-branch/css.txt
 U   Pete-branch
Checked out revision 6.
$ svn merge -c3,6 file:///path/to/repo/test/trunk Pete-branch
--- Merging r3 into 'Pete-branch':
U    Pete-branch/css.txt
--- Merging r6 into 'Pete-branch':
U    Pete-branch/other.txt
$ svn diff Pete-branch/
Property changes on: Pete-branch
___________________________________________________________________
Modified: svn:mergeinfo
   Merged /trunk:r3,6

Index: Pete-branch/other.txt
===================================================================
--- Pete-branch/other.txt   (revision 6)
+++ Pete-branch/other.txt   (working copy)
@@ -1 +1,2 @@
-another file
\ No newline at end of file
+another file
+Unrelated change
\ No newline at end of file
Index: Pete-branch/css.txt
===================================================================
--- Pete-branch/css.txt (revision 6)
+++ Pete-branch/css.txt (working copy)
@@ -1,4 +1,4 @@
 This is a test
-more lines
+more lines Pete's change
 even more
 Dave's change
$ svn commit Pete-branch/ -m "Merged Pete's changes"Sending        Pete-branch
Sending        Pete-branch/css.txt
Sending        Pete-branch/other.txt
Transmitting file data ..
Committed revision 7.

# Now the test: is Dave's change still there? Yes!
$ svn cat file:///path/to/repo/test/branches/r1/css.txt
This is a test
more lines Pete's change
even more
Dave's change

Проблема не возникла, понимаете? И это все равно было бы правдой, если бы мы выполняли шаги в другом порядке - попробуйте!

Так что же может пойти не так? Скорее всего, неправильное разрешение конфликтов слияния:

Например, возможно, Пит проверил свою рабочую копию ветки до того, как Дейв слил свои изменения. Он все еще может нормально объединить свои изменения, но когда он попытается выполнить фиксацию, svn будет жаловаться, что его рабочая копия устарела. Он должен обновить свою рабочую копию. Это добавит изменение Дэйва в его рабочую копию; поскольку изменение Дейва затрагивает тот же файл, который также изменил Питер, SVN попытается объединить изменения в файле. Если изменения далеки друг от друга, это произойдет автоматически.

Но если изменения находятся в одной строке или очень близко друг к другу, SVN не сможет объединить их и пометить их как конфликтующие. Теперь Питу нужно разрешить конфликт. Один из вариантов - просто использовать его версию, отбросив изменения Дэйва. Если он это сделает, изменения Дэйва будут потеряны . Вместо этого он должен отредактировать файл (с помощью TortoiseMerge или, возможно, вручную), чтобы он содержал оба изменения.

Лучшая установка, которую я видел:

• Магистраль всегда строится и тестируется, и вы "можете" запустить ее в любое время.
• Вы создаете теги из магистрали, когда готовы к освобождению и экспорту из тега.
• теги (v.1.0.233, v.1.1.013 и т. Д.)

• В филиалах выполняется вся разработка. Ошибки и особенности. И после тестирования сливаются в ствол. Возможно в ветке «Тестирование».

   корень 
   - ствол 
   - ветви 
   - ошибка 1 
   - ошибка 2 
   - функция 1 
   - теги { {1}} - v.1.0.233 
   - v.1.1.013 
   

Вот еще одна структура svn, которую следует рассмотреть, и она мало чем отличается от процесса, который мы используем для такой же большой базы кода:

root
 - tags
    - project-name-1.0.1
    - project-name-1.0.2
    - ...
 - branches
    - reviewed
    - stable
 - trunk

Все коммиты выполняются в ствол , так же, как и сейчас. Это полезно, потому что вы обнаруживаете все конфликты во время первоначальной регистрации кода.

Однако вместо того, чтобы объединять изменения в стабильную ветку, вы объединяете изменения для ревизий утвержденных / проверенных исправлений ошибок или функций во что-то вроде веток / обзор . Было бы неплохо указать номер билета и исходную версию в svn: log . Затем, когда вы будете готовы обновить сервер одобренными изменениями, вы можете выполнить автоматическое слияние со стабильной веткой, поскольку любые странные конфликты будут обнаружены на более раннем этапе процесса.

Вы можете столкнуться с некоторыми конфликтами на втором шаге, поскольку вы применяете исправления не по порядку.Subversion должна уметь справиться с этим, но если вы столкнетесь с какими-либо проблемами, стратегия их решения будет следующая:

Найдите ревизию в основной ветке, которая содержит только одобренные изменения, затем

1. выборочно объедините последующие одобренные изменения в порядок или
2. Объединить все ревизии от r {all-Approved} до CURRENT , затем выполнить обратное слияние каждого последующего неутвержденного набора изменений

Обе из них будут проблемой, но опять же, это не должно происходить очень часто.

И последнее: большинство наших разработчиков используют TortoiseSVN, как и вы, но вы можете сэкономить много времени, выполняя такого рода операции слияния с помощью сценариев bash или даже сценариев perl / php. Вы можете подумать о настройке Unix-бокса или виртуальной машины для этой единственной цели.