Насколько Детализированный Ваши “проекты” SVN: один большой проект, содержащий несколько releated приложений или один "проект' на приложение
Как-то так?
array =[' HHHHHHH HHHHHHHHHHH HHHHHHHHHHHHHHHHHHH ',
' E E EEE ',
' TT ',
' CC CCCC']
result = []
for pos in zip(*array): # create tuples of chars from the same index in all strings
char = ''.join(pos).replace(' ', '') # remove all space chars
if char: # if there's anything left (ie. skip the char at index 0)
result.append(char[-1]) # then append the char from the array closest to the bottom
result = ''.join(result) # convert back to string
print result
, который печатает
EHHHHHHHEHHHHHHHHHHHTTCCEEEHHHHHHHHHHHHHHHHHHHCCCC
10 ответов
Спасибо за ввод. Я не буду «выбирать» ответ, потому что думаю, что у всех есть ценные моменты. Избегание преждевременной оптимизации действительно кажется ключевым, так как делает макет как можно более простым на данный момент. Мы переходим к одному проекту, содержащему приложения, потому что 90% времени мы выпускаем ВСЕ вместе. Следовательно, усложнять вопросы с одним приложением на проект, кажется, не имеет смысла. Даже когда мы идем в Maven, вполне вероятно, что все артефакты Maven для данной версии будут сделаны из одной и той же ветви. Мы всегда можем изменить его позже, если потребуется использовать историю SVN и «рыбий глаз», чтобы держать нас в здравом уме.
Мы будем рефакторинг макета исходного кода так же, как и рефакторинг исходного кода. Когда проект начинает «плохо пахнуть» из-за ситуации с зависимостями, мы разбиваем его, но не до этого. Вероятно, я буду использовать обхват во времени, а не в пространстве: время для сборки и тестирования, время для оформления заказа. Если у меня есть дерево объемом 1 ГБ, которое я могу оформить менее чем за 10 минут, а собрать / протестировать менее чем за 30 минут, мне не нужно его разбирать, если только мне не требуется часто его выпускать.
Итак, спасибо за вход. Это действительно помогло мне сформулировать вопрос для моей команды и оценить варианты.
Мы поместили все проекты, связанные с одним приложением, в одного представителя SVN. просто для удобства обслуживания, централизации кодовой базы приложения только в одном репозитории, а также возможности управления взаимозависимостями между различными ресурсами приложения.
Обычно мы разделяем наши ресурсы на разные папки в транке. эта классификация в основном основана на функциональной / модульной группировке или многоуровневой группировке [DAL, BLL, GUI и т. д.]. это полностью зависит от того, как вы структурировали код. Надеюсь, это поможет.
Я использую отдельные проекты и объединяю их, чтобы сформировать решение через svn: externals.
Книга SVN содержит хорошее обсуждение обоих подходов.
В конце я бы выбрал то, что кажется более естественным для пользователей репозитория.
Лично я Я предпочел единый подход к соединительным линиям / тегам / веткам SVN со всеми моими реальными проектами кода в их собственных папках внутри них.
Однако для большей кодовой базы (я управлял только 3-4 небольшими проектами, которые были частью одного решения), я бы настоятельно рекомендовал перейти на разделенный подход.
Я использую как отдельные проекты, так и комбинированные проекты в зависимости от размера проекта. Для наших крупных проектов каждый из них находится в отдельном репозитории и имеет независимые процедуры сборки и развертывания. Для наших небольших проектов у нас есть репозиторий «tools» для их хранения, причем каждый подпроект является подкаталогом корневого каталога.
Я также поддерживаю «личный» репозиторий, в котором люди могут хранить свои тестовые программы в виде одноразовых утилит или других вещей, которые могли бы извлечь выгоду из контроля версий и централизованного резервного копирования, но не принадлежат как независимый проект.
Одно приложение / модуль, который развертывается независимо для каждого проекта. Использование одного проекта затрудняет введение циклов выпуска, если вы когда-нибудь обнаружите, что вам нужно Maven -ish управление зависимостями с модулем в зависимости от стабильных реализаций других модулей. Это также может привести к тому, что люди просто будут использовать случайный полезный код из других приложений напрямую, вместо того, чтобы вычленять его из графика, чтобы сохранить график зависимостей Sane (tm).
Вы должны проводить интеграционное тестирование, используя надлежащие наборы тестов и практики КИ с четко определенной а не полагаться на то, что половина вашего кода внезапно завершится с ошибкой, если одна часть сломается.
Другая проблема с наличием одного uber-проекта состоит в том, что это довольно обременительно для пользователей git-svn, которые работают только с одним модулем.
Расти органично. Предварительная оптимизация - корень всего зла, однажды сказал Дейкстра. Также помните о YANGI (вам это не понадобится).
Каждое приложение получает свою собственную папку с trunk / tag / branch. Если проект в приложении становится действительно большим, то он помещается в отдельную папку и может быть связан с приложением во время сборки (или даже с svn: externals).
Тем не менее, если требования вашего проекта разработайте сложное приложение, написанное 10 разработчиками, и вы являетесь привратником или мастером сборки, тогда вы можете рассмотреть более сложные альтернативы.
Храните отдельные репозитории SVN для отдельных проектов. Последнее, что вы хотите - это иметь День слияния
Возможно, вы захотите проверить Номер редакции Subversion в нескольких проектах .
I've found this solution to work well and be readable for other people:
age = Date.today.year - birthday.year
age -= 1 if Date.today < birthday + age.years #for days before birthday
Easy and you don't need to worry about handling leap year and such.
Под этими номерами у нас есть номера версий продукта - так эффективно мы отбрасываем концепцию транка, у нас есть только каталоги тегов - самое большое число - это транк (мы должны сделать это, так как мы должны поддерживать несколько версий проектов одновременно). Слияние происходит по мере необходимости, поэтому, если я обновлю ошибку в проекте А, версия 3.0; Я объединю эти изменения с версией 4.0 и версией 5.0.Если бы я делал репо только с одним или двумя проектами, у меня может возникнуть соблазн сохранить структуру ветвей / тегов, но с другой стороны - я вероятно, я бы оставил директории явным образом в главном дереве (при условии, что я не выпускал достаточно часто для регулярной маркировки) (я использую номер ревизии в качестве «тега», кстати, и храню там двоичные файлы. Поэтому, если мне нужно получить конкретная старая ревизия, Я могу выбрать правильный бинарный файл, посмотрев журнал)
Его удивительно легко управлять, учитывая, что у меня есть репозиторий 10 Гб с ревнумом, в настоящее время превышающим 300 000, с большим количеством старого кода и новым. Я бы порекомендовал структуру другим и буду использовать ее снова.
Кстати, еще одна причина, по которой теги dir не будут работать для нас, заключается в том, что мы выпускаем каждый раз, когда появляется ошибка или запрос на изменение, независимо от того, насколько он крошечный. Наш каталог тегов через некоторое время станет неуправляемым, поэтому мы используем revnum в качестве тега - мы можем связать его с трекером ошибок, чтобы сделать его более читабельным для человека.
Итак, подведем итог в грубом виде, у нас есть каталог структура, подобная этой, где v1 и v2 являются версиями продукта:
maint/source/v1.0/projectA
maint/source/v1.0/projectB
maint/source/v2.0/projectA
maint/source/v2.0/projectB
etc
очевидно, мы могли бы поместить dir ветви в «source», и ветвь / тег под каждым подпроектом, но это было бы сложно, если бы нам нужно было выпустить 2 подпроекта как один запрос на изменение (как мы это делаем довольно часто). Помещение тега subdir в исходный каталог означает, что мы помечаем все, когда изменяется только один подпроект (что не соответствует нашему требованию по отслеживанию каждого подпроекта отдельно)