Управление исходным кодом – отдельное ответвление требуется для каждого продукта?
26 байтов!..
, Поскольку URL подразумевает, это можно рассмотреть.. обман:
http://github.com/dbr/so_scripts/tree/master/golf_tdoc/cheating.bash
8 ответов
Предел виртуального адресного пространства процесса Win32 составляет 1,5 ГБ (не совсем верно). Кроме того, в платформах .NET существует ограничение на процент памяти, который может потреблять процесс .NET. В файле machine.config есть элемент processModel с атрибутом memoryLimit, который представляет собой% доступной памяти, которую процесс может использовать. Значение по умолчанию - 60%.
Если компьютер, на котором вы работаете, имеет 2 ГБ памяти или вы не включили переключатель / 3GB в вашем BOOT.INI, то вы получите ~ 1,3 ГБ памяти на каждый
Я не могу найти статью в базе знаний, но, если я правильно помню, .NET 1.x не может обращаться за пределами лимита 1,5 ГБ (1,8 ГБ?) независимо от ваших настроек.
http: //blogs.msdn .com / tmarq / archive / 2007/06/25 / some-history-on-the-asp-net-cache-memory-limits.aspx http://social.msdn.microsoft. Таким образом, сервер может предоставить некоторые или все данные, которые мы ищем. Для целых чисел он может построить их с помощью простой арифметики (двойной или двойной и добавить 1 для каждого бита), для битов он просто предоставляет соответствующий зашифрованный бит.
Мы можем смешивать и сопоставлять логические и целочисленные значения в наших проектах, получая if / then / else (что требует оценки стиля SIMD обеих ветвей) путем вычисления cond * then + (1 - cond) * else, используя 1 как истину и 0 как false в cond, так что вы можете обойтись без использования встроенной арифметики вашего кольца, чтобы сделать ваши схемы более мелкими.
С другой стороны, мы могли предварительно зашифровать некоторые данные, но поскольку вы ' Придется повторно использовать один и тот же набор ключей, чтобы сделать это правильно.
Итак, теперь у нас есть данные, предоставленные сервером. Теперь зашифруйте то, что вы не делаете Я хочу, чтобы сервер знал, что именно вы ищете, и попросил их передать это в схему в нужных точках, скажем, в качестве дополнительных входных данных для вашей функции карты.
Мы должны иметь возможность отображать произвольная NC1-подобная схема для каждого входа для извлечения поля, умножения некоторых значений и, как правило, преобразования его в форму, которую вы можете легко уменьшить.
Затем уменьшите эти фрагменты, используя более мелкие схемы, например, для простого моноида, который дает хорошо ограниченный результат. (то есть вы сопоставляете, чтобы получить бит, который указывает, нашли ли вы совпадение, а затем вы уменьшаете, подсчитывая эти биты с помощью небольшой схемы сумматора)
Поскольку вам нужно только логически построить схему и смоделировать ее выполнение на этих зашифрованных битах в гомоморфном кольце вы, вероятно, могли бы относительно быстро реализовать это, используя небольшой DSL, т.е. добавить новую функциональность в общую библиотеку, а также в компоненты, специфичные для продукта
Я храню общий код в собственной папке продукта. Затем используйте svn: externals , чтобы поделиться кодом с другими продуктами. Обработка ветвления и слияния немного болезненна, но это лучше, чем иметь четыре копии общего кода в репозитории. Примерно так (замените trunk на /branches/RB-1.0.0 или /tags/REL-1.0.0 для веток выпуска и выпусков с тегами):
/core/trunk
/product_a/trunk
/core (svn:externals 'core /core/trunk')
/product_b/trunk
/core (svn:externals 'core /core/trunk')
/product_c/trunk
/core (svn:externals 'core /core/trunk')
/product_d/trunk
/core (svn:externals 'core /core/trunk')
UPDATE0 : обратите внимание, что /product_a/tags/REL-1.0 .0 может использовать /core/tags/REL-1.0.0, а /product_b/tags/REL-1.0.0 может использовать /core/tags/REL-1.1.0
Общие функции могут быть разработаны в отдельной ветви платформы, при этом каждый продукт получает свою собственную ветку для разработки конкретного продукта.
Это не прямой ответ на ваш вопрос, потому что я не уверен на 100%, что существует универсальный вариант. "ответ, который можно дать. Но Джефф написал отличное сообщение в блоге о ветвлении .
Put them all in one branch. You want to know at development time if a change in product A breaks product B. This is much better than getting into a merge mess when you discover that ProductB had to rewrite half of your common codebase your other 3 depend on as-is.
EDIT: To clarify, I mean they should all share a development branch. I would advise a separate Production branch to represent the code that is in production, and a Maintenance branch if you do regular bugfix releases.
У нас похожий сценарий. У нас есть общие библиотеки для ведения журнала, доступа к данным и безопасности, но эти библиотеки используются в нескольких проектах. Мы создаем отдельный набор веток для каждого продукта, а затем используем внешние SVN для связи с общими библиотеками. Таким образом, общие библиотеки поддерживаются в «общей» ветви для всех проектов, в то время как все проекты имеют независимые ветви.
Таким образом мы можем гарантировать, что все продукты построены на основе последней версии общих библиотек, в то время как проекты также могут обслуживаться независимо.
Ветвь в самой высокой точке вашего дерева. IE, он должен включать код для всех ваших проектов, общих модулей ... и, возможно, таких вещей, как документация / сценарии сборки / установщики и т. Д. Почему? Почему бы нет! Ветвления дешевы во всех упомянутых до сих пор системах (SVN, TFS, Perforce, git).
Эта тактика особенно важна в системах, которые используют ветвление по «пространству путей» (TFS, Perforce). В противном случае создание сборки полного набора продуктов, согласованной для разных рабочих мест, становится кошмаром при обслуживании.
После того, как вы примените это на практике, вы можете изменять столько или меньше кодовой базы, сколько захотите. в данной ветке. Вы всегда можете выполнить полную сборку, чтобы проверить проблемы интеграции; возможность слияния любых компонентов между любым набором ветвей остается открытой для вас. Но вопрос стратегии SDLC полностью ортогонален. Вы можете ветвиться для каждой функции, команды, выпуска или любой комбинации вышеперечисленного; вы можете определить критерии прямой / обратной интеграции, как вам нравится. * Тот факт, что каждая ветвь является надмножеством, оказывается преимуществом во многих стратегиях и никогда не должен быть недостатком, если ваши инструменты справляются с этой задачей.
* Выбор стратегии - это индивидуальный вопрос, который зависит от множества факторов. Другие предложили несколько хорошо известных документов, которые помогут вам принять решение. Я бы поместил самую последнюю версию руководства Microsoft по TFS туда, вместе с лучшими из них.
Но вопрос стратегии SDLC полностью ортогонален. Вы можете ветвиться для каждой функции, команды, выпуска или любой комбинации вышеперечисленного; вы можете определить критерии прямой / обратной интеграции, как вам нравится. * Тот факт, что каждая ветвь является надмножеством, оказывается преимуществом во многих стратегиях и никогда не должен быть недостатком, если ваши инструменты справляются с этой задачей.* Выбор стратегии - это индивидуальный вопрос, который зависит от множества факторов. Другие предложили несколько хорошо известных документов, которые помогут вам принять решение. Я бы поместил самую последнюю версию руководства Microsoft по TFS туда, вместе с лучшими из них.
Но вопрос стратегии SDLC полностью ортогонален. Вы можете ветвиться для каждой функции, команды, выпуска или любой комбинации вышеперечисленного; вы можете определить критерии прямой / обратной интеграции, как вам нравится. * Тот факт, что каждая ветвь является надмножеством, оказывается преимуществом во многих стратегиях и никогда не должен быть недостатком, если ваши инструменты справляются с этой задачей.* Выбор стратегии - это индивидуальный вопрос, который зависит от множества факторов. Другие предложили несколько хорошо известных документов, которые помогут вам принять решение. Я бы поместил самую последнюю версию руководства Microsoft по TFS туда, вместе с лучшими из них.
* Тот факт, что каждая ветвь является надмножеством, оказывается полезным во многих стратегиях, и никогда не должно быть недостатком, пока ваши инструменты соответствуют этой задаче.* Выбор стратегии - это индивидуальный вопрос, который зависит от множества факторы. Другие предложили несколько хорошо известных документов, которые помогут вам принять решение. Я бы поместил самую последнюю версию руководства Microsoft по TFS туда, вместе с лучшими из них.
* Тот факт, что каждая ветвь является надмножеством, оказывается полезным во многих стратегиях, и никогда не должно быть недостатком, пока ваши инструменты соответствуют этой задаче.* Выбор стратегии - это индивидуальный вопрос, который зависит от множества факторы. Другие предложили несколько хорошо известных документов, которые помогут вам принять решение. Я бы поместил самую последнюю версию руководства Microsoft по TFS туда, вместе с лучшими из них.
Мы создали серию сайтов с общей базой и большим количеством настраиваемого кода с помощью git, структурировав его как серию ветвей.
Основная ветвь содержала основной код, и каждая ветвь этого мастера была определенной настройкой ядра. При внесении изменений в ядро их было легко передать в ветви, сохраняя при этом каждую настраиваемую версию изолированной.
18 сайтов и проект продолжительностью более 12 месяцев с командой из 7 человек, и все еще под контролем!