Контроль версий для нескольких экземпляров развивающегося кода - PullRequest
2 голосов
/ 04 ноября 2010

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

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

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

Точно так же внутренний код постоянно развивается по мере добавления новых возможностей.Многие из них должны быть объединены в транк, чтобы они были доступны для будущих приложений.Тем не менее, есть также несколько хаков для конкретных случаев, которые транк не должен видеть.

Как нам организовать этот беспорядок?Очевидно, чем проще, тем лучше.

Ответы [ 2 ]

1 голос
/ 04 ноября 2010

Мы действительно стараемся, чтобы наши проекты содержали отдельно:

  • исходные файлы (управляемые в любой VCS по вашему выбору, например SVN)
  • конфигурационные файлы (специфичные для команды илиокружение)

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

Для файлов такого типа, которыми мы управляли в VCS:

  • шаблонов
  • сценариев, способных взять этот шаблон и сгенерировать (приватный(как и в версии без версии). Конфигурационный файл с нужными значениями-in / merge.
    Эта база данных может быть при необходимости версирована в свою собственную VCS (см., например, SO вопрос или, в качестве альтернативы, этот )
0 голосов
/ 05 ноября 2010

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

Использование контроля версий с отслеживанием проблем, которое связывает проблемы с фиксацией кода, значительно повышает производительность.

Относительно структуры репозитория, по крайней мере, с точки зрения subversion, есть только соглашения, но нет строгих правил, налагаемых инструментом. Как насчет дерева под названием «ствол», где управляется весь «общий код».

Для каждого инженерного задания создается ветка. Это не что иное, как «папка проекта» с контролем версий. Исходный код, относящийся к другим проектам, будет объединен обратно в транк.

...