Каковы эффективные методы управления владением программами в системах управления версиями?

Question

Используя SVN или Git, мне пришла в голову мысль, что я использую структуру каталогов в качестве хранилища метаданных. Каждая команда будет иметь каталог в общем репозитории для своего кода. Чем больше я думаю об этом, тем хуже выглядит идея. Причина, по которой мне кажется плохой идеей, является то, что команды не являются статическими объектами. Команды могут исчезать, разделяться, рекомбинировать и даже получать новое имя. Я знаю, что я использую уникальный идентификатор и, возможно, внешнюю базу данных. Я, вероятно, даже сталкиваюсь с репозиторием каждой команды для надлежащего управления правами доступа. В ситуации с 200 или более командами мне лучше всего поддерживать владение во внешней базе данных или есть некоторые инструменты и методы, которые я мог бы изучить?

Answer 1

Вот моя лучшая попытка указать вам в правильном направлении. Вообще говоря:

Организуйте исходный код в соответствии с компонентами вашей системы обычным способом. Убедитесь, что каждый компонент может иметь независимое управление доступом (например, в git, это означает отдельные репозитории для каждого компонента, как сказал Макис).

Управление правами доступа обычно осуществляется совместно с LDAP в наши дни. Настройте свой инструмент, чтобы использовать LDAP-каталог вашей организации обычным способом. (для git это чаще выполняется с использованием существующих учетных записей в системе, которые могут быть или не поддерживаться LDAP).

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

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

Answer 2

Вот как я это видел. Совместите структуру каталогов по связанным технологическим линиям. Сейчас это, вероятно, команда. Используйте базу данных или что-то, чтобы сопоставить двоичные файлы (или исходные файлы) с членами команды. Затем, когда все перемещается, все, что вам нужно сделать, это обновить базу данных.

Если вы сделаете корень довольно широким, у вас будет меньше реорганизации, чем если бы вы сделали его маленьким.

Answer 3

Чтение ваш вопрос, я имел представление о том, что может быть полезно для вас (или нет, это просто идея вспышка, которая появилась в моей голове вдруг ;-):

1. Как с Linux " devtodo ', вы можете создать файл в каждом каталоге для метаданных. (Для devtodo файл называется «.todo»)
2. Этот файл метаданных может быть файлом базы данных nosql с членами команды в данный момент.
3. Этот файл метаданных может находиться в контрольной версии.
4. Этот файл метаданных может быть соединен (как операция соединения sql) с другими файлами, то есть всеми членами ваших команд.
5. Набор сценариев или псевдонимов оболочки может быть определен для записи более часто используемой командной строки nosql.

В нескольких строках: файлы базы данных отношений в вашем git или svn с вашими метаданными; и нет серверов баз данных.

Answer 4

Метаданные, которые вы хотите сохранить, состоят в том, чтобы сохранить информацию о файлах и членах команды, которые работали с ресурсами. Предполагая, что у вас есть зрелая семантика обработки ресурсов в вашем репозитории, например комментарии для регистрации и т. Д., Одна стратегия может заключаться в том, чтобы идентифицировать метаданные, которые вы просматриваете, и индексировать их с помощью некоторого инструмента индексации/api. Существует масса информации, доступной из метаданных репозитория, которые можно получить и проиндексировать. Если вам нужен более тонкий контроль, вы можете использовать настраиваемые перехваты для фиксации, чтобы заставить членов команды размещать необходимую информацию во время проверки. Репозиторий метаданных, который у вас был бы, даст хороший контроль для запросов/поиска пользователей и ресурсов. Индексирование может выполняться скриптом ежедневно/еженедельно.

Answer 5

Git не имеет прав доступа очень хорошо. Чтобы даже начать обрабатывать его, вам нужно будет использовать gitosis, а затем написать код в git-крючки. У меня был question относительно этого.

Тогда вам понадобится, как вы сказали, база данных для обработки информации о том, какой пользователь может получить доступ к этому репозиторию. То есть вам нужно разбить материал на отдельные репозитории в git, поскольку вы не можете защитить отдельные файлы или каталоги в git. Я написал короткий blog note об этом некоторое время назад. Суперпроекты могут помочь в будущем, но эта концепция все еще строится и не очень четко определена.

В таких профессиональных инструментах, как Rational ClearCase, у вас есть лучшие инструменты для этого. Например, вы можете создавать компоненты и определять права пользователей на один компонент. К сожалению, даже эти инструменты требуют обширных обновлений вручную, если многое изменится. Но если права пользователя - это все, что вам нужно, было бы гораздо экономичнее писать свои собственные инструменты, а не покупать один из этих монстров.

Answer 6

Дайте каждой команде собственный репозиторий.

Answer 7

ОК, так что если я понял ваш вопрос правильно, то у вас есть
1. Несколько программ
2. Несколько команд, которые работают на исходном коде
3. А нужно отслеживать, какие команды работают, на которых код

Вы не указываете, будет ли каждый раз работать только с одной программой или может ли эта программа работать совместно несколькими командами.

Я не GIT или SVN пользователь, мой главный опыт с-неволей, но я попытаюсь кратко изложить некоторые рекомендации, которые должны работать на любой системе SCM большого уровня предприятия

1. имеют основную линию code - это будет ваша «чистая» область.
2. Создать песочницу ветвь для каждой команды
3. Используй четкие соглашения об именах

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

Так что в плане расположения хранилища, то есть что-то вроде этого

• кода
  • магистрального
    • program1
    • PROGR am2
  • команда
    • teamA
      • program1
    • teamB
      • program2

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

После того, как команда рада они имеют хорошую следующую итерацию своего кода, то лидер команды только имеют разрешения на поощрение и интегрировать изменения UPTO магистрального

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

Если команда распускаются, то вы можете отказаться от ветки, если вы хотите
Если поменяется название команды затем создать новую SANbox ветку для новой команды, а затем интегрировать изменения из старой команды песочницы новой песочницы

На perforce вы можете сделать некоторые напуганные вещи, такие как обратные интегралы, которые действительно приятны, потому что вы можете вытащить магистраль в свою ветку, выполнить любые слияния, а затем интегрировать обратно в магистраль. Пока ничего не изменилось в коде, тогда интеграция просто становится прямой копией. Это имеет то преимущество, что выталкивание «сломанной» магистрали вниз в песочницу и удержание магистральной линии

В любом случае, это некоторые мысли от меня.Управление СКМ весь район сам по себе, и я уверен, что много других людей там будет иметь некоторые лучшие решения, но выше подход работает для меня

Некоторые полезные ссылки на этой сложной области :)
Software Life Cycle Modelling
High-level best practices in SCM
SCM intro - repositories
SCM intro - branches

Answer 8

Если это отдельный проект, просто дать ему хранилище самостоятельно.