Структура репозитория SVN - Почему это лучше?
Я имел, это много раз происходит, и это - реальная боль.
Во-первых я предложил бы пытаться следовать за отслеживанием стека, обеспеченным разработчиком, хотя я нашел, что часто просто перечисляет набор материала внутренностей, который не полезен.
, Если это не работает тогда компиляция попытки и определение исключения оттуда. Вы действительно летите слепой, который является проблемой. Вы могли тогда попытаться просто выполнить код и видеть, какое исключение повышено при выполнении его который должен дать Вам еще некоторую информацию.
А подход в последнюю минуту мог быть должен удалить весь несгенерированный код из формы и постепенно повторно представлять его для определения ошибки.
при использовании пользовательских элементов управления Вы могли бы вручную удалить сгенерированный код, связанный с пользовательскими элементами управления также, если предыдущий метод все еще приводит к ошибке. Вы могли тогда повторно представить это постепенное таким же образом для определения, какой пользовательский элемент управления вызывает проблему, затем пойдите и отладьте это отдельно.
В основном, насколько я могу сказать, нет никакого реального пути вокруг проблемы кроме сильно ударить его немного!
9 ответов
Такой способ организации репозитория:
ReponsitoryMain
Project1
branches
trunk
tags
Project2
...
лучше всего подходит, когда ваши проекты не связаны / не зависят друг от друга. Наоборот, упрощается версия для всего пакета проектов. Поэтому, если вы часто выпускаете / упаковываете Project1 и Project2 вместе, лучше всего, чтобы они использовали одну и ту же ветвь.
Если, с другой стороны, ваш проект сильно разобщен и над ними работают совершенно разные команды, тогда вы бы не сделали этого. Большую часть времени нет необходимости проверять их все вместе, поэтому вы можете использовать описанный выше метод.
Структура репозитория зависит от ваших потребностей. Если ваши проекты полностью разделены (между ними нет зависимостей), тогда подойдет эта «простая» структура репозитория. Если у вас есть зависимости в вашем проекте (например, некоторые глобальные «библиотеки инструментов», общий код), вы должны использовать другую структуру, например:
trunk
prj_a
prj_b
tags
<YOUR_TAGNAME>
prj_a
prj_b
branches
<YOUR_BRANCHNAME>
prj_a
prj_b
или что-нибудь еще, что имеет больше смысла для вашего процесса.
В простой структуре с локальная магистраль / теги / ветки невозможно (по крайней мере, чисто) пометить несколько проектов, если между ними есть зависимости.
Также часто предлагаемый подход «нескольких репозиториев» не восполнит этот пробел, поскольку тогда вы обречены на наличие нескольких ревизий или тегов в нескольких репозиториях.
Основная проблема заключается в том, что SVN не имеет НЕТ поддержки общих ресурсов и их тегирования / разветвления.
Если вы думаете о своей структуре репозитория, вы должны спросить себя, в каком процессе вы хотите поделиться своими библиотеками кода.
Мы храним отдельный репозиторий для каждого проекта.
Хотя это не позволяет вам копировать и хранить файлы истории версий из одного проекта в другой, это позволяет вам архивировать весь репозиторий после завершения проекта.
Большинство людей делают это, потому что это рекомендовано в книге о Subversion .
Вот хорошее объяснение от директора проекта CollabNet Subversion:
http: / /blogs.collab.net/subversion/2007/04/subversion_repo/
Магистральные ветви и теги действуют одинаково. Как вы их используете, зависит от вас.
Я использовал эту структуру в течение многих лет и еще не нашел времени, чтобы она не адаптировалась к тому, что мне нужно было делать.
Вот что у нас есть. Это работает, и на данный момент этого достаточно (потому что мы никогда не знаем, что принесет будущее) У нас нет веских причин тратить драгоценное время (и деньги) на поиск, возможно, более оптимальной структуры.
М.
В моем магазине у нас есть что-то вроде этого:
RepositoryMain
Trunk
proj 1
proj 2
..
Dev
Team1
proj 1
proj 2
Team2
proj 1
proj 2
...
Я не знаю, как это работает в большинстве мест, но, похоже, работает неплохо
Все команды разработчиков могут работают отдельно над своими собственными проектами, объединяясь из основной ветки в свой проект, когда они начинают разработку / улучшение, а затем снова объединяются в основную часть после их завершения.
Хорошо, я собираюсь быть немного более проповедником и решительно выступлю за то, чтобы иметь ствол, теги и ветки для каждого проекта.
Основная альтернатива - иметь единый ствол, теги и ответвления со всеми проектами внизу. Однако это приводит к ряду проблем, одна из которых является значительной, и я подробно расскажу здесь:
В первую очередь это прокладывает путь к библиотеке неприкасаемых, где каждый боится прикоснуться к конкретной библиотеке, потому что любое изменение может сломать что-то незаметное в каком-то случайном проекте. Причина этого в том, что, поскольку нет разделения между проектами, любой может эффективно изменить код в вашем проекте, при этом вы не сможете его обнаружить или контролировать.
Что происходит: в один прекрасный день вы проверяете свой проект, и он строится, на следующий день вы проверяете его, и он терпит неудачу, но вы не внесли никаких изменений в свой проект. Случилось так, что кто-то изменил библиотеку, от которой вы зависели. В большой структуре со многими зависимостями Для разработчика нереально тестировать изменения своей библиотеки для каждого проекта, особенно если им приходится вносить критические изменения. Что вам нужно в вашем проекте, так это ссылка на конкретную версию библиотеки. Таким образом, библиотека обновляется только тогда, когда вы меняете ссылку на последнюю версию.
Этот вид ссылки имеет 3 эффекта: 1 ваш проект изолирован от случайных промежуточных изменений в разработке библиотеки. 2 вы получаете ревизию в вашем проекте , в которой говорится, что «Сейчас я использую эту версию библиотеки». 3. Вы можете контролировать, когда вносите изменения в свой проект, чтобы учесть любые критические изменения в библиотеке.
Есть и другие проблемы, которые я могу решить, если этого недостаточно.
Что вам нужно в вашем проекте, так это ссылка на конкретную версию библиотеки. Таким образом, библиотека обновляется только тогда, когда вы меняете ссылку на последнюю версию.Этот вид ссылки имеет 3 эффекта: 1 ваш проект изолирован от случайных промежуточных изменений в разработке библиотеки. 2 вы получаете ревизию в вашем проекте , в которой говорится, что «Сейчас я использую эту версию библиотеки». 3. Вы можете контролировать, когда вносите изменения в свой проект, чтобы учесть любые критические изменения в библиотеке.
Есть и другие проблемы, которые я могу решить, если этого недостаточно.
Что вам нужно в вашем проекте, так это ссылка на конкретную версию библиотеки. Таким образом, библиотека обновляется только тогда, когда вы меняете ссылку на последнюю версию.Этот вид ссылки имеет 3 эффекта: 1 ваш проект изолирован от случайных промежуточных изменений в разработке библиотеки. 2 вы получаете ревизию в вашем проекте , в которой говорится, что «Сейчас я использую эту версию библиотеки». 3. Вы можете контролировать, когда вносите изменения в свой проект, чтобы учесть любые критические изменения в библиотеке.
Есть и другие проблемы, которые я могу решить, если этого недостаточно.
1 ваш проект изолирован от случайных промежуточных изменений в разработке библиотеки. 2 вы получаете ревизию в вашем проекте , в которой говорится, что «Сейчас я использую эту версию библиотеки». 3. Вы можете контролировать, когда вносите изменения в свой проект, чтобы учесть любые критические изменения в библиотеке.Есть и другие проблемы, которые я могу решить, если этого недостаточно.
1 ваш проект изолирован от случайных промежуточных изменений в разработке библиотеки. 2 вы получаете ревизию в вашем проекте , в которой говорится, что «Сейчас я использую эту версию библиотеки». 3. Вы можете контролировать, когда вносите изменения в свой проект, чтобы учесть любые критические изменения в библиотеке.Есть и другие проблемы, которые я могу решить, если этого недостаточно.
В таких системах, как CVS, у вас не было отдельных «каталогов». Вы просто отметили и разветвили.
Однако SVN больше смоделирован на идее моментальных снимков, и поэтому "копии" материала выполняются очень эффективно. Вместо того, чтобы маркировать или иным образом отмечать специальные (или альтернативные) версии проекта, проще (и эффективнее) сделать его именованную копию.