views:

21

answers:

3

There are many visual studio solutions on our company svn, with different teams working on different areas. Some of our projects are re-useable library projects.

The problem comes when someone makes a breaking change in a library project that is part of a specific solution..... How does that person know what other solutions will possibly be affected?

Is there some tool out there that can recursively go through the file system, opening up VS projects and build a dependency graph so I can see at a glance what solutions will be affected?

A: 

<brainstorm>
    alternatively you could use svn's precommit hook to run unittests
    of the committed items and deny the commit when a test fails
</brainstorm>

zolex
Are you saying svn knows which solutions to run unit tests on when I commit a change to a common project? If that is so, I could just introduce a bug, try to commit it, and then svn will tell me which solutions are affected in the commit-failure message!
stitty
somehow I don't think svn is that smart. CruiseControl might be smart enough.... but it only kicks in after the commit (the whole reason you suggested the svn precommit hook in the first place)
stitty
well an svn-hook is simply a bash-script so you can do anything you want. i use a fixed structure for my library so i can easily detect if a test exists for the committed class and run it :)Class: Some_Class_AnywhereSource: libs/Some/Class/Anywhere.phpTest: tests/Some/Class/Anywhere.php
zolex
The whole point of my question is to find that bash script.... The one that determines automatically which solutions to compile and run tests for when I change a source file. Its not a valid solution to have to manually write scripts for each project.... There are too many opportunities for someone to forget something.... I need a catch all, and the script I found below should do it.
stitty
+1  A: 

We use continuous integration to detect whether someone has made a breaking change so do not need to find out the dependency graph (well sort-of, see below).

What this does is building all solutions with all their projects inside each time there was a commit to SVN. Of course we need to know the sequence of the solutions (6 solutions, so that is bearable). Inside of each solution the projects (up to 65) are set up with their dependencies so they build in the correct order. We use a build grid of three agents to keep the response time low.

As a consequence we know within one hour or less whether a change broke the build.

In your situation other factors might be at work so the solution that works fine for us may be unsuitable for you.

John
Hmmmm I want to make a decision about whether to make a breaking change or not WAY BEFORE I commit it to the repository.Don't you think that breaking the build is a bit of an "ambulance at the bottom" approach?
stitty
@stitty: Yes, you are right. I'd definitely expect team members to do what is doable to avoid breaking changes in the first place. However, sometimes it looks good on your computer, it looks good on your colleagues computer, you both commit within a short time frame and bang! Another scenario would be large system where it might not be feasible in all cases to build the entire system first on your PC before the commit.
John
@John: We use continuous integration here, and I agree that it is a very useful ambulance at the bottom, however it is NOT what my question is about. I need a way of visualizing solution dependencies in order to make decisions about making breaking changes in a library component.
stitty
A: 

install cygwin and run

find . -name "*.sln" -exec grep -q "*ProjectName.csproj*" '{}' \; -print

from the root folder of your repository.

You will get a print out of all the sln files that include the project. I thought I could do this from windows vista, but the "advanced search" functionality in windows explorer sucks the big one. You cannot specify both a file pattern and a content pattern.

stitty