Question

I have the following goals:

1. Shared source control with continuous integration
2. The ability to check in incremental changes that may or may not build (i.e., breaking changes) without affecting other team members
3. The ability, without days of work, to get a report of the incremental changes checked in (not a report of the FACT that a check in was made, but an actual diff report – late edit: I now know this to be a “unified diff”)

One possible solution is to use TFS as the primary source control with continuous integration and then use personal subversion implementations on top of that for tracking and checking in incremental changes that could break the build.

I understand TFS has the shelve option, but I don’t think TFS has a nice summary report of check-in diffs (see below), nor is there a way that I know of to easily see a diff for a shelveset.

So, the questions are:

1. Does anyone know how to get an SVN report of check-ins with something like this for each file (or, for that matter, how to get something like this out of TFS):

        SetErrorMessage("You have entered an invalid concentration.");
        return;
      }
-     c.Concentration = decimal.Parse(concentration);
+     decimal num = 0;
+     if (decimal.TryParse(concentration, out num))
+        c.Concentration = decimal.Parse(concentration);
+     else
+     {
+        SetErrorMessage("Invalid concentraion.");
+        return;
+     }
+
      c.UnitOfMeasure = units;

2. Does anyone have experience with overlapping source control?

3. And finally, does anyone know how these goals could be accomplished using only TFS or only SVN (or something else)?

Thanks for any input.

Answer 1

SVN can do both.

1. Shared source control with continuous integration

“Shared source control” is just what SVN does.

SVN itself does not do continuous integration (CI), but there are many CI servers that integrate well with SVN (CruiseControl, CruiseControl.NET, Jenkins, Hudson…). In the OS community the motto is often “do one thing, but do it well”, thus SVN does not bundle CI functionality, but just integrates with whatever CI server you use.

2. The ability to check in incremental changes that may or may
   not build (i.e., breaking changes)
   without affecting other team members

This is commonly done using branches. Basically, you create a (virtual) copy of the source tree, then commit your changes there, separate from the main repository tree (the so-called trunk). When you’re satisfied, you integrate (“merge”) the changes from your branch into the trunk.

Alternatively, you could work such that you code always builds. I would actually consider that a better solution :-). Still, branches will be necessary for disruptive changes, or changes that need thorough testing.

3. The ability, without days of work, to get a report of the
   incremental changes checked in (not a
   report of the FACT that a check in was
   made, but an actual diff report – late
   edit: I now know this to be a “unified
   diff”)

The list of branches (which usually live all in one directory) will give you the list of various changes that are not yet in the trunk. For each branch, you can then use svn diff to get a diff to the trunk (calculate the diff between the HEAD in the branch and the HEAD in trunk).