3

After adopting Kiln a year or so back, I've been sticking to the convention of having one source control project per one visual studio project. While I find this keeps the commits nice and simple and the source control project very focused, its starting to lead to a LOT of commits for what's essentially one change.

Example: One of my visual studio solutions is setup like this:

  • App.Core (service layer)
  • App.Core.Tests( testing layer)
  • App.Web.Core (controllers )
  • App.Web.UI (views/js/etc..)
  • App.Web.Admin (administrative site for the web)
  • App.Web.Tests (testing layer)
  • App.ChromeExtension

Eventually I'll be adding an andriod and iphone view layer as well (probably monotouch/monodriod)

Say I add a feature on the service layer side that required an update to the interface, I then have to propagate that change through the various web methods and maybe even the chrome extension. That's pretty straight-forward, but it could mean me having to do up to 7 different commits for what's essentially a single "change". It also means pulling a lot of changes for other developers or for myself when I switch to/from my laptop.

Can someone who's dealt with large projects comment on what the "best" approach is here? Do I stick with the multiple source control projects so each commit tree is super concise and deal with the overhead? Do I stick everything in a single source control project for simplicity? Do I do a hybrid where I merge anything web related into one project, and anything service related into another project? Or something else?

For reference: the project is maintained by a UX developer and myself, but that could easily change in future.

(also: I wasn't sure if this was programmers or stackoverflow worthy, and decided to go here instead. If a mod wants to move it I've no objection.)

Thanks!

TheRightChoyce
  • 3,054
  • 1
  • 22
  • 19

1 Answers1

3

As soon as you have inter-dependent components (set of files, here solutions), where one change to one module has to propagate to the others, you could consider a "system" approach (i.e. one repository, with everything in it):
That make sense if you consider that you cannot have a tag on just one module without setting that tag on all the others.

If those components can be developed independently one from another, you could mitigate the number of commits by scripting them, like in this script 'git-submodule-recur.sh:' (here for Git):

#!/bin/sh

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

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

One command would then commit in every submodules:

git-submodule-recur commit -a -m "some comment"
Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250