System life cycle versus development project versus Team Project versus source control branch et
System life cycle versus development project versus Team Project versus source control branch etc.
I have spent some time exploring the new source control system in Team System now and I haven’t got the grip about the relationships between System lifecycle management, development projects, team project and version control folders/branches. Maybe someone can explain how Microsoft has thought about this and Team System?
Some thoughts:
A typical system/application has a lifecycle that spans idea, requirement collection, specification, development, testing, deployment, bug fixing, testing, deployment, operation, changed requirements, development, testing, deployment (upgrade), operation, retirement. So from a development perspective this means that we have an initial development project called 1.0, a maintenance project called 1.1 and a second development project called 2.0. 1.0 will be represented by a Team Project with a corresponding version control folder. 2.0 will be another Team Project with a version control branch that is branched from 1.0. 1.1 will be another branch from 1.0 but will it be a Team Project – maybe so if the amount of work fixing and doing minor enhancements is reasonable large. I don’t think that 1.1 will exist in the 1.0 Team Project neither will 2.0.
So far I haven’t found a way of creating a Team Project that is connected to an already existing version control folder/branch by the way – anyone who knows if this is possible?
The source control system does not allow one to merge between the 1.1 and 2.0 branches by the way – something that may be legitimate in some more complex scenarios with bug fixing branches to parallel maintenance tracks. Comments?
The GUI doesn’t seem to support comparing directory structures although the command line tool allows this. I hope this will change or that I am wrong!
Regards
Christer O.
You wouldn't necessarily need to create a new Team Project for each release (1.0, 1.1, 2.0, etc.). If you want to create a clean divide between the set of work items, versioned items, etc., then it's a good idea. But if you just need branches of the versioned items, you can keep all of the releases under one team project.
The Team Project Creation Wizard has a page where you select options for Source Control - you can skip it, create a new folder (prompts for a location, defaults to $/TeamProjectName, I think), OR branch from an existing folder - I think that's what you were looking for.
So, you could create 1.0 and 2.0 Team Projects, and even elect to have the 2.0 source start as a branch of 1.0. If 1.1 is a branch of 1.0 (typical), and 2.0 is a branch of 1.0, then you indeed wouldn't be able to "normally" merge between 1.1 and 2.0 directly. The merge command line supports a "baseless" mode where you could pend a baseless merge for items between those two branches directly, but as you can probably guess, this can be a tricky operation.
I thought you could launch a compare from a folder in the Source Control Explorer. I'll dig into this; it may have been cut for v1 but I agree it's something worth having.
Chris mentions that you can keep all the releases under one team project, which makes sense to me (less clutter).
In the GUI interface for Beta 3, you can branch at the individual VS solution level, and it would seem also at the aggregate level (the container which is the team project itself). However, it seems to get confused if you try to branch the container.
e.g.,
Team Project: MyTeamProject
has solutions DBInterface.sln, WebServices.sln
In the GUI, if I go to Source Control under Team Explorer, right click on MyTeamProject and select "Branch", it shows the Source as $/MyTeamProject, and prompts for a target. No matter what I put in, it doesn't like it, other than a separate Team Project, which is exactly what I'm trying to avoid. If I enter MyTeamProjectV2, it prompts for a directory, then tells me the path must start with $/ (Error TF10125). If I enter $/MyTeamProjectV2, it tells me I must branch into an existing Team Project (Error TF10198). If I Enter $/MyTeamProject/MyTeamProjectV2, it tells me that the target item cannot be under the source item.
I'm very willing to be told that I am confused - since I am. I know I could branch each individual VS solution underneath the project, but that leaves all kinds of clutter, and I think of all the solutions as part of my V2. Perhaps I just need to create a new team project, but I'd like to get a bit more direction and understanding before I do so.
Thanks
Bruce, Team Foundation is designed such that top-level folders (e.g., $/MyTeamProject) must be created through the Team Project Creation Wizard. Source control will not allow you to create a branch that is a child of the source of the branch (e.g., branching $/MyTeamProject to $/MyTeamProject/TheBranch is not allowed).
Given those two rules, you end up in your current jam. There are a couple of possibilities for getting out of it. First, you could create another Team Project using the Team Project Creation Wizard and select to create a branch of an existing team project on the source control page of the wizard. Of course, you mention that you'd like not to have to do that.
The second possibility is to add a level in the hierarchy. You can treat $/MyTeamProject as the root for your project. Under it, you could create subdirectories that represent releases, branches, etc. For example, you could have the following.
$/MyTeamProject
Main
v1.0
v1.1
You could then create a branch of Main for each release (or you could create a label and branch by label version if you actually need the branch).
Buck
