Соглашение об именах SVN: хранилище, ветки, теги
Это работает для меня.
import smtplib
from email.mime.text import MIMEText
s = smtplib.SMTP('smtp.uk.xensource.com')
s.set_debuglevel(1)
msg = MIMEText("""body""")
sender = 'me@example.com'
recipients = 'john.doe@example.com,john.smith@example.co.uk'
msg['Subject'] = "subject line"
msg['From'] = sender
msg['To'] = recipients
s.sendmail(sender, recipients.split(','), msg.as_string())
4 ответа
У меня есть ствол , ветки , теги и рабочие области под корнем репозитория.
- магистраль - не используется, чтобы избежать путаницы
- ветки - ветки выпуска, срок жизни одного выпуска составляет около года, названный акронимом названия продукта и текущим годом (LDN_FSHCHPS_REL_2010)
- тегами - неизменяемые метки выпуска / исправлений (выполняются с помощью svn copy ), автоматически генерируются из метки времени (LBL_20100526180134 = 2010-05-26 18:01:34), версии релизов генерируются из той же метки времени, что и v10 .05.26.180134, поэтому можно легко сопоставить метку с рабочим пространством версии
- - функция / отдельные ветки разработчика, расти из ветвей / LDN_FSHCHPS_REL_2010 для новой разработки или из тегов / LBL_20100526180134 для исправлений, ветвление выполняется с помощью svn copy , обратное слияние - с помощью svn merge , реинтеграция выполняется с помощью svn merge --reintegrate . рабочие области называются точно так же, как WS_, где автоматически генерируется скриптом (как автоинкремент)
Все находится в одном репозитории с ежечасным / ежедневным / и т. д. резервные копии. Все шаги, такие как ветвление, маркировка, слияние и построение, написаны для удобства и стабильности (сценарии проверяют целостность репозитория).
Ветвление / слияние разрешено только для каталогов второго уровня и только для полных слияний, а не для отдельных файлов / каталогов (скажем, branch / LDN_FSHCHPS_REL_2010 -> workspaces / WS_345), чтобы включить автоматическое слияние и избежать проблем с информацией о слиянии поддеревьев (и также, чтобы облегчить первопричину проблем слияния, когда они случаются)
Сейчас мы используем следующие стандарты с SVN ...
Обычно теги изменяемы. Причина, по которой вы помечаете выпуск, заключается в том, что вы можете применять исправления ошибок, пока разработка продолжается в основной ветке. Конечно, те же самые исправления ошибок должны быть применены к основной ветви.
Итак, если ваш проект похож на Backyard Baseball for Youngins, как вы с этим справитесь?
Мы - магазин Java, поэтому все наши проекты называются gov.bop.project. :-) Subversion работает с любыми именами.
Если вы придерживаетесь парадигмы функциональных веток, как вы называете свои функциональные ветки?
Мы используем номер, сгенерированный нашей системой отчетов об инцидентах. Это облегчает проверку.
Похоже, что теги лучше всего выиграют от номеров версий.
Мы обнаружили, что даты ггггммдд лучше работают в долгосрочной перспективе.
camelCase? Нет, мы не накладываем никаких ограничений на имена, за исключением того, что пробелы, как правило, не приветствуются. Важно содержание, а не представление. До тех пор, пока имя четко определяет, что оно делает, мы счастливы.
Я думаю, что самое большое изменение, которое вы можете сделать, это поместить все ваши проекты в одно репо на верхнем уровне.
Мы не используем ветки или каталоги тегов, поскольку у нас много сотен проектов, каждый из которых разделен на версионные группы (т.е. у нас есть базовая платформа, которая версионна, и множество плагинов, которые живут под каждым номером версии базы)
например:
base v1
+--- moduleA
+----moduleB
base v2
+--- moduleA
+----moduleB
Мы думали о размещении ветки тегов под каждым каталогом модулей, но мы почти всегда имеем дело с головной версией, поэтому для нас это не проблема. Мы регулярно сливаем изменения из модулей старых базовых версий в новые - например, делаем изменение в модулеА для базы v1, изменения сливаются в модульА базы v2. Мы не возвращаемся назад, если в этом нет необходимости.
Каждый модуль имеет примечание к релизу, в котором описывается номер версии и изменения. В комментарии к журналу есть часть описания и номер версии. Это позволяет очень легко выпускать предыдущие версии без необходимости иметь множество веток тегов с уникальными именами. Если бы мы начали использовать ветки тегов (это было предложено), то мы бы сделали копию полного пути в каталог /tags), мы бы все равно объединились в одну ветку тегов и поместили комментарий к журналу, отмечая номер релиза, у нас просто слишком много модулей, чтобы управлять ими как 1 папкой тегов на ветку. И нет, мы никогда не вносим изменения в исторические ревизии - если клиенту нужна новая функциональность, он должен обновиться до последней версии (что никогда не является проблемой, пока они не изменят версию базовой платформы)
Мы также не используем ветки, так как мы обычно работаем над головной версией каждого модуля, если нам нужна ветка для большого набора изменений, мы делаем ветку на уровне базы, поэтому мы создаем ветку "base v2 - performance" и ветвим все. Это упрощает группировку большого количества изменений вместе, так как так получается лучше для нас. Ветвление отдельных модулей привело бы к слишком большому беспорядку в репозитории - поскольку у нас их несколько сотен, было бы легко потерять их, если бы у нас были ветки по каждому модулю.
Да, мы вносим изменения в ствол, но это нормально для нашего рабочего процесса - вещи не фиксируются, пока они не готовы к работе. Все изменения, которые вносятся в старые базовые версии - это только исправления ошибок, и у нас слишком много модулей, чтобы управлять ими в полном цикле dev-test-release. Мы исправляем, если оказывается, что это плохое исправление, мы исправляем снова. Иногда мы меняем этот подход для более крупных разработок и создаем ответвление в папке branches (вне корня). Путь ветви воссоздает путь к исходному модулю (так что легко определить, что это за модуль, а слияние обратно происходит так же просто, как изменение /branches на /trunk в начале пути).
Единственная проблема, с которой мы столкнулись в этой системе, это когда мы поместили модуль в проект веб-приложения (redmine). Мы хотели иметь один проект redmine для всех версий модуля, но наша схема была такова, что стало немного сложно указать корень репозитория. Если бы мы могли связать путь к репозиторию с каждой версией в redmine, то это ограничение исчезло бы.
Это не обязательно лучший вариант для всех, и я бы рекомендовал больше использовать ветви, но это работает для нас (отчасти потому, что так мы работали в предыдущей системе контроля исходников, которая была "безопасной" и не поддерживала ветвления/слияния).
Я использую модель модель "ствол, теги, ветви".
Ствол: всегда должен быть в стабильной форме. (не обязательно релизный, но стабильный, т.е. без ошибок компилятора) Я обычно вношу незначительные изменения и новые возможности, которые невелики и могут быть завершены менее чем за один день. Если я буду разрабатывать что-то, что займет несколько дней, и проверки оставят ствол в нестабильном состоянии, я создам ответвление.
ветви: предназначены для разработки функций, которые могут оставить ствол в нестабильном состоянии. Они также используются для "тестирования" новых возможностей и идей. Я обязательно делаю слияние обновлений из ствола в ветку, чтобы последние разработки в стволе синхронизировались с моей веткой.
tags: предназначены для релизов или стабильных версий кода, к которым я хочу быстро вернуться. Обычно я использую их для конкретной версии (1.00) модуля или приложения. Я стараюсь не делать никаких отметок в тегах. Если есть ошибки, то эти изменения вносятся в trunk и будут там в следующем релизе. Единственное исключение, которое я делаю - это экстренные ошибки. Это подразумевает, что тег прошел надлежащую QA's и является достаточно стабильным.