Как каждый справляется с несколькими ответвлениями выпуска в подверсии?
Я использую 2 и 4, где применимый (т.е. когда я знаю высоту содержания или если переполнение не вредит). Где-либо еще я иду с решением 3. Между прочим, Ваше первое решение имеет преимущество перед 3 (что я могу определить), потому что это не является больше семантическим, так как это использует тот же фиктивный элемент.
Между прочим, я не был бы обеспокоен четвертым решением, являющимся взломом. Взломы в CSS только были бы вредны, если их базовое поведение подвергается реинтерпретации или другому изменению. Таким образом, Ваш взлом, как гарантировали бы, не будет работать. Однако в этом случае Ваш взлом полагается на точное поведение, которое overflow: auto предназначено для имения. Никакой вред в подтягивании бесплатной поездки.
5 ответов
Если честно, я не совсем уверен, как работает ваша система, исходя из описания. Однако в прошлом мне приходилось управлять проектами с несколькими живыми версиями. Мы сделали это следующим образом:
- Ничего не выпускается, что не было сначала в стволе.
- Каждая версия получает свою собственную ветку версии.
- Единственный способ обновить ветку версии - это слияние из ствола.
- 1269] Таким образом, мы могли выбрать, какие функции были в какой версии. Используя отслеживание слияния, это также позволило нам создать веб-страницу, которая графически показывала нам, что и куда делось.
Ключевым моментом является наличие одной полностью интегрированной ветви, из которой вы можете выбирать - это мое определение ствола.
Это не идеальная система. Если вы пропустили версии, то зависимости усложняли задачу, и нам действительно нужна была графическая вещь, чтобы показать нам, что и где, но в целом работало хорошо.
Также см. Мой ответ здесь .
Это не то, чем отличается черепаха. Для выполнения сложных сценариев слияния и ветвления вам понадобится что-то вроде спецификации конфигурации clearcase для управления версиями.
Если вы используете черепаху, вам лучше всего оставить магистраль таким, а затем либо запустить непрерывную интеграцию на магистрали, либо создать ветки для каждой функции, объединяя их обратно, когда разработка функции будет завершена. Если вы сделаете это, то у вас будет только проверенный код на транке. Затем вы выбираете точку выпуска, выполняете интеграцию и возвращаете необходимые исправления в свою магистраль, но также позволяете вашим командам продолжить разработку.
Я думаю, вы хотите отслеживать слияние либо через svnmerge.py, либо через встроенное отслеживание слияния из Subversion 1.5. Это позволяет заблокировать некоторые изменения от объединения в ветку, что затем может быть сделано для всех изменений, связанных с функциями, которые вы хотите включить только в следующий выпуск.
Вы почти всегда хотите, чтобы изменения в первой отложенной ветви присутствовали во второй. Таким образом, вторая ветвь выпуска должна быть создана из первой ветки выпуска, а изменения из первой должны периодически объединяться. В идеале те же люди, которые их создали.
В этом случае хорошо подойдет разветвление по спирали (?) - просто оставьте ствол и взбирайтесь наверх.
У моей компании были похожие проблемы.
У нас был проект, отложивший выпуск одного релиза - мы ' Назовем его 2.0 - через несколько месяцев. Тем временем у нас были проблемы с производством в текущей ветке - назовем ее 1.5 - что требовало дополнительных выпусков. Мы не могли использовать транк, потому что у него были запрещенные функции, поэтому мы начали переходить от веток. Наш релиз 1.6 - ответвление от 1.5, а не багажник. Помимо соглашения об именах, версия 1.6 на самом деле не более чем 1.5.1. Поскольку это не СОП, мы очень тщательно документировали то, что делаем.
И я не с нетерпением жду точки слияния, когда мы наконец-то объединим ветвь 1.6 и 2.0. Мы не можем объединить изменения 1.6 обратно в основную часть или 2.0, потому что это только делает QA на 2. 0 проблемы все хуже. Мы используем Subversion 1.4.6, поэтому программное обеспечение не поможет - все будет объединено вручную.