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

Ответ 1

Что, черт возьми, мы делаем неправильно?

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

Вы должны определить ветвь в процессе разработки (а не на разработчика) и объединить эти ветки в ветке до выпуска (чтобы включить все одобренные разработки для выпуска), с окончательным слиянием для выпуска, когда все разработки были проверены вместе.
Если каждая разработка достаточно последовательна для каждого разработчика, это означает, что каждый разработчик может поддерживать одно рабочее пространство для общей задачи и проверять только соответствующее рабочее пространство для этого набора задач: количество фактически изменяемых файлов будет небольшим, что значительно сократит время проверки.

См:

• назначение ветвления
• ветки и SVN
• объединить рабочий процесс (чтобы свести к минимуму конфликты во время слияний)

Ответ 2

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

# let 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 change
 even more
$ svn commit Pete-trunk/ -m "Pete 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 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 change
 even more
+Dave change
$ svn commit Dave-trunk/ -m "Dave change"Sending        Dave-trunk/css.txt
Transmitting file data .
Committed revision 4.

# Dave 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 change
$ svn commit Dave-branch/ -m "Merged Dave 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 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 change
 even more
 Dave change
$ svn commit Pete-branch/ -m "Merged Pete 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 change still there? Yes!
$ svn cat file:///path/to/repo/test/branches/r1/css.txt
This is a test
more lines Pete change
even more
Dave change

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

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

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

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

Ответ 3

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

Из того, что вы говорите, чего хотите достичь, кажется, что вы правы: лучшим решением было бы иметь одну ветвь для каждой функции, а затем объединить их по очереди в туловище и выборочно в ветки релиза. Subversion не кажется лучшим инструментом для такого развития. Если вы используете DVCS, например hg или git, у вас может быть один репозиторий для каждого разработчика, попросите их как можно скорее слить/направить их изменения в туловище, чтобы проверить максимальное количество интегрированных функций и найти потенциальные проблемы. Но у вас также будет еще один репозиторий, называемый "релиз", который поддерживается только одним человеком, который будет выборочно выбирать такую ​​и такую ​​функцию/патч из ваших репозиториев разработчиков. Например, в hg, который я знаю лучше, когда вы вытягиваете изменения, которые еще не были объединены (например, от dev-repo до репозитория release), создаются mutiple "head", т.е. Какие-то анонимные ветки, а вы может решить изменение путем изменения, функция по признаку, если вы хотите объединить эти "головки" в основную ветку не.

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

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

Cheers,
Кристоф.

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

Ответ 4

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

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

• Филиалы находятся там, где все разработки выполнены. Ошибки и возможности. И после тестирования сливаются в ствол. Возможно, в ветке "Тестирование".

  root
   - trunk
   - branches
     - bug 1
     - bug 2
     - feature 1
   - tags
     - v.1.0.233
     - v.1.1.013
  

Ответ 5

Здесь другая структура svn для рассмотрения и не похожа на процесс, который мы используем для такой же большой базы кода:

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

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

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

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

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

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

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

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