This project has moved and is read-only. For the latest updates, please go here.

Existing VS Project--Import into TFS & Restructuring

Feb 9, 2012 at 8:04 PM

I read the branching guidance and found it very explanatory and helpful.

I have an existing Visual Studio "monolithic" project that I want to place under version control now that we have a TFS server available. The problem with the existing project is that it started off as one of those infamous "we'll write this and only use it once" utilities which is now in full-time service.

Because the original code was meant to be thrown away, all of the project's components are in a single solution in a single project (i.e. the data access, the UI, and custom UI components/controls).

The code at this point is fairly stable with only one more planned addition. However, this addition could result in some breaking changes (due to the nature of the earlier code being throw-away, loose-coupling was not a design goal at first, but is now necessitated by this latest change). In addition, obviously I would like to refactor the solution structure by splitting out the various concerns into separate projects, e.g. a data access project, a custom components and controls DLL project, as well as the main application project, at least.

As far as branching is concerned, I think we'll stick with the Development<->MAIN<->Service->Release structure.

My questions are:

  1. Is it better to bring this solution and project into TFS now, before restructureing, and then restructure?
  2. Or should I restructure first, fixing anything that breaks and then place the restructured solution under TFS?

If #1 is a viable option, is there any guidance/documentation/best practices available regarding the scenario of bringing an existing codebase under source code control?

Thanks.

CS

 

Feb 9, 2012 at 8:28 PM

Ha, it seems that all it takes is the right keywords in your search and you get the answers you're looking for. In this case, "restructure" was the right keyword (vs. split).

Anyway, this question was posed on an MSDN forum, and the answer turned out to be---surprise, surprise---branch!

The gist was, get your project into TFS--creating the MAIN branch with the current codebase. Then branch again, perform your restructuring, and merge back to MAIN once everything is stable.

Above, I said I wanted the structure Development<->MAIN<->Service Release->RTM. I would have an additional branch called Restructure, which would dead-end as soon as it is merged back into MAIN. I could do one of two things with this branch once I've completed restructuring:

  1. Delete it. This will not remove history, but will prevent any other branches or check-ins from occurring on that branch. This is OK if I'm sure I'll never need to restructure again, or if I do need to restructure again, I want to use a separate branch.
  2. Keep it around, but mark it as read-only until if/when I restructure again.

Personally, I hope I'll never restructure again, but I think I'll take option 2 anyway, as it's more transparent to me and provides more of a visible "audit trail" of what occurred to the code between the time it was originally placed under source control and subsequently had a merge back into MAIN.

Regards,

CS

Feb 9, 2012 at 9:52 PM
I am glad you found your answer.
Any reason you don't simply do the restructuring in your dev branch? I see no harm in having the Restructure branch. But I don't see why you would need it.
Regards,
David Allen

Sent from my iPhone

On Feb 9, 2012, at 2:28 PM, fourpastmidnight <notifications@codeplex.com> wrote:

From: fourpastmidnight

Ha, it seems that all it takes is the right keywords in your search and you get the answers you're looking for. In this case, "restructure" was the right keyword (vs. split).

Anyway, this question was posed on an MSDN forum, and the answer turned out to be---surprise, surprise---branch!

The gist was, get your project into TFS--creating the MAIN branch with the current codebase. Then branch again, perform your restructuring, and merge back to MAIN once everything is stable.

Above, I said I wanted the structure Development<->MAIN<->Service Release->RTM. I would have an additional branch called Restructure, which would dead-end as soon as it is merged back into MAIN. I could do one of two things with this branch once I've completed restructuring:

  1. Delete it. This will not remove history, but will prevent any other branches or check-ins from occurring on that branch. This is OK if I'm sure I'll never need to restructure again, or if I do need to restructure again, I want to use a separate branch.
  2. Keep it around, but mark it as read-only until if/when I restructure again.

Personally, I hope I'll never restructure again, but I think I'll take option 2 anyway, as it's more transparent to me and provides more of a visible "audit trail" of what occurred to the code between the time it was originally placed under source control and subsequently had a merge back into MAIN.

Regards,

CS

Feb 10, 2012 at 4:05 AM

David:

Well, I guess two reasons. One, the code was stable in its current form. Two, up until now, all the code had been developed outside of any source code control. Therefore, I had no development branch or even a main branch!

So my thought process was:

  1. Since the code, in its current structure, is stable, then the current codebase should serve as my "main" branch. If I did no restructuring, then development branches would be based off of this codebase, which is now Main.
  2. While I could have created a "devolpment" branch or some sort of version branch in which to perform the restructuring, I felt that creating a Restructure branch made it clear that this particular branch was a major restructuring of the existing codebase; no development or refactoring was done in this branch aside from adding namespaces and references to various (new) projects and existing code files. In fact, I'm not even considering this restructuring a "new version", per se. It is simply a re-arrangement of the existing codebase.

Once the changes in Restructure are complete and the project is once again compiling with no errors, I will merge Restructure back into Main. Effectively, the Restructure branch will replace my "stable" Main branch, becoming my new Main branch codebase on which all other developmental releases will be based.

Anyway, I guess it's a matter of preference; and the intent expressed by this structure seemed more clear to me.

Thanks.

CS