Результаты поиска

Дебаты по дизайну: каковы хорошие способы хранения и управления версионными объектами?

Я намеренно оставляю это довольно расплывчатым на первый взгляд. Я ищу обсуждения и какие вопросы важны больше, чем я ищу трудные ответы.

Я нахожусь в середине разработки приложения, которое делает что-то вроде управления портфелем. Дизайн, который у меня есть до сих пор, - это

• Проблема: проблема, которую необходимо решить
• Решение: предлагаемое решение одной или нескольких проблем
• Отношение: отношение между двумя проблемами, двумя решениями или проблемой и решением. Далее разбивается на:
  • Родитель-ребенок - своего рода категоризация / иерархия дерева
  • Перекрытие-степень, в которой два решения или две проблемы действительно решают одну и ту же концепцию
  • Адреса-степень, в которой проблема обращается к решению

Мой вопрос касается временной природы этих вещей. Проблемы возникают, а затем исчезают. Решения имеют ожидаемую дату разрешения, но она может быть изменена по мере их разработки. Степень взаимосвязи может меняться с течением времени по мере развития проблем и решений.

Итак, вопрос: каков наилучший дизайн для версирования этих вещей, чтобы я мог получить как текущую, так и историческую перспективу своего портфолио?

Позже: возможно, я должен сделать это более конкретным вопросом, хотя ответ @Eric Beard стоит того.

Я рассмотрел три проекта баз данных. Я буду достаточно каждого, чтобы показать свои недостатки. Мой вопрос: Что выбрать, или вы можете придумать что-то лучше?

1: проблемы (и отдельно, решения) являются самореферентными в управлении версиями.

table problems
  int id | string name | text description | datetime created_at | int previous_version_id

  foreign key previous_version_id -> problems.id

Это проблематично, потому что каждый раз, когда я хочу новую версию, я должен дублировать всю строку, включая этот длинный столбец description .

2: Создайте новый тип отношений: версия.

table problems
  int id | string name | text description | datetime created_at

Это просто перемещает отношения из таблиц проблем и решений в таблицу отношений. Та же проблема дублирования, но, возможно, немного "cleaner", так как у меня уже есть абстрактная концепция отношений.

3: Используйте более Субверсионную структуру; переместите все атрибуты проблемы и решения в отдельную таблицу и версируйте их.

table problems
  int id

table attributes
  int id | int thing_id | string thing_type | string name | string value | datetime created_at | int previous_version_id

  foreign key (thing_id, thing_type) -> problems.id or solutions.id
  foreign key previous_version_id -> attributes.id

Это означает, что для загрузки текущей версии проблемы или решения я должен извлечь все версии атрибута, отсортировать их по дате, а затем использовать самую последнюю. Это может быть не так уж и страшно. Что кажется мне действительно плохим, так это то, что я не могу проверить эти атрибуты в базе данных. Этот столбец value должен быть свободным текстом. Я могу сделать столбец name ссылкой на отдельную таблицу attribute_names , которая имеет столбец type ,но это не заставляет правильный тип в таблице attributes .

еще позже: ответ на комментарии @Eric Beard о внешних ключах с несколькими таблицами:

Увы, то, что я описал, является упрощенным: есть только два типа вещей (проблемы и решения). На самом деле у меня есть около 9 или 10 различных типов вещей, поэтому у меня будет 9 или 10 столбцов внешних ключей под вашей стратегией. Я хотел использовать наследование одной таблицы, но эти вещи имеют так мало общего, что было бы крайне расточительно объединять их в одну таблицу.

Возможно ли автоматически производить выезды из любого VCS?

Давайте рассмотрим среду веб-разработки, в которой разработчики извлекают проект на свои локальные компьютеры, работают над ним и регистрируют изменения в процессе разработки.
Эти изменения далее тестируются на развитие и перемещаются в прямом эфире по регулярному графику (например, еженедельно, ежемесячно и т. д.).
Возможно ли иметь автоматическое перемещение последней помеченной версии (а не последней проверки, поскольку это не может быть стабильным 100%), например, 8 утра в понедельник утром, либо используя скрипт, либо встроенную функцию VCS?

Как лучше всего использовать версию файла и версию Assembly?

В .NET есть два номера версий, доступных при построении проекта, версия файла и версия Assembly. Как вы используете эти цифры? Оставить их прежними? Автоматическое увеличение одного, но ручное изменение другого?

А как насчет атрибута AssemblyInformationalVersion ?

Я нашел эту статью в базе знаний Майкрософт поддержки (KB), которая предоставляла некоторую помощь: как использовать версию Assembly и версию файла Assembly .

Получение номера репозитория subversion в коде

Я хотел бы реализовать способ записи версии проекта в коде, чтобы его можно было использовать при тестировании и отслеживать ошибки. Похоже, что лучшим номером версии для использования будет просто текущий номер версии из Subversion. Есть ли простой способ закрепить это число в заголовочном файле (C++ в моем случае) или что-то еще, что я могу получить в коде? Я думаю, что это пост-коммит-крючок или что-то в этом роде?

Есть ли у кого-нибудь опыт реализации этого (с кодом для обмена, пожалуйста?), или может предложить лучшую альтернативу? Спасибо.