Несколько проектов в решении против нескольких проектов в системе контроля версий

Question

После принятия Kiln примерно год назад, я придерживался соглашения о том, что на один проект визуальной студии приходится один проект управления исходным кодом. Хотя я нахожу, что коммиты остаются красивыми и простыми, а проект управления исходным кодом очень целенаправленным, его начало приводить к МНОГОМ коммитам для того, что по сути является одним изменением.

Пример: Одно из моих решений для Visual Studio настроено так:

• App.Core (сервисный слой)
• App.Core.Tests (тестовый слой)
• App.Web.Core (контроллеры)
• App.Web.UI (views / js / etc ..)
• App.Web.Admin (административный сайт для Интернета)
• App.Web.Tests (слой тестирования)
• App.ChromeExtension

Со временем я добавлю слой просмотра andriod и iphone (возможно, monotouch / monodriod)

Скажем, я добавляю функцию на стороне сервисного уровня, которая требует обновления интерфейса, затем мне нужно распространить это изменение с помощью различных веб-методов и, возможно, даже расширения Chrome. Это довольно просто, но это может означать, что мне нужно сделать до 7 разных коммитов для того, что по сути является одним «изменением». Это также означает внесение множества изменений для других разработчиков или для себя, когда я переключаюсь на / с моего ноутбука.

Может ли кто-то, кто имеет дело с крупными проектами, прокомментировать, какой здесь «лучший» подход? Должен ли я придерживаться нескольких проектов управления исходным кодом, чтобы каждое дерево коммитов было очень лаконичным и справлялось с накладными расходами? Для простоты я вставляю все в один проект управления исходным кодом? Я делаю гибрид, где я объединяю что-нибудь, связанное с Интернетом, в один проект, и что-нибудь, связанное с другим проектом? Или что-то еще?

Для справки: проект поддерживается разработчиком UX и мной, но это может легко измениться в будущем.

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

Спасибо!

Answer 1

Как только у вас есть взаимозависимые компоненты (набор файлов, здесь решения), где одно изменение в одном модуле должно распространяться на другие, вы можете считать "системой"подход (т. е. один репозиторий со всем в нем):
Это имеет смысл, если вы считаете, что у вас не может быть тега только на одном модуле без установки этого тега на всех остальных.

Еслиэти компоненты могут быть разработаны независимо друг от друга, вы можете уменьшить количество коммитов, написав их, как в этом сценарии 'git-submodule-recur.sh:' (здесь для Git):

#!/bin/sh

case "$1" in
        "init") CMD="submodule update --init" ;;
        *) CMD="$*" ;;
esac

git $CMD
git submodule foreach "$0" $CMD

Одна команда будет затем фиксироваться в каждом подмодуле:

git-submodule-recur commit -a -m "some comment"