Sharing code, invalid references after merge.

Dec 15, 2010 at 4:24 PM

HI there, i need some advice how to structure my solution so the merging of branches works transparently and efficient.

Today, my solutions are referencing other projects by adding project references.
These project references creates relative paths in the solution file and becomes a problem when i merge my projects.

For the branching i have follwed the simple branching guid, with one dev, main and release branch.
(HOL_Quick_Start_Basic_Branch_Plan_2010_v1.pdf)

When i merge my dev branch, the project references gets invalid since they are relative.
From this guid, what i dont really understand is that when i creae my dev branch from the main source folder, the guide tells me that the path should be (see page 9):
$/eBanking1/Dev/Dev where dev is duplicated. If i instead would create a branch like $/eBanking1/Dev then i guess that i wouldnt have the problem with invalid relative paths when merging back to the main branch or what?

Why are the /Dev folder duplicated in the guide?

Any tips?

Regards Niclas

 

Developer
Dec 15, 2010 at 7:04 PM

Niclas,

Lets use the following example

Create a TeamProject : BasicBranch ($\BasicBranch)

Create a folder, Main ($BasicBranch\Main)

add your solution to the Main folder

Create another folder, Common ($\BasicBranch\Common).

Convert Common to a branch.

Branch Main to Dev within a folder called Development (Branch $\BasicBranch\Main -> $\BasicBranch\Development\Dev)

At this point Main is a branch (the source of the preceding branch operation and Dev is a branch (the target of the preceding branch operation)

The branch Dev is contained in a folder, Development that is created during this branch operation (or it could already exist)

So in your question there is no duplication of Dev in the guide. There is a TeamProject (eBanking1), it contains a folder (Dev) which contains a branch (Dev). If it is easier for you to understand, simply change the names of Dev so they are not the same.

As for your problem, with the project reference, I have never had problems with project references being valid following a branching operation.

How did you add the project reference?

I assume the referenced project is in the same Team Project?

Is the referenced project part of the solution?

Changing the location of the Dev branch should not affect your problem with referenced projects

What problem are you encountering with the merge?

Regards,
Bill Heys
VS ALM Ranger

 

Dec 16, 2010 at 1:36 PM
wheys wrote:
.......

I assume the referenced project is in the same Team Project?


Bill,

How would you recommend dealing with references that are in a different Team Project?

We currently use relative reference to some common stuff in another Team Project, when branching in the manner described there is an extra folder in the DEV branch path. I know one option would be to branch from the 'common' stuff in the other Team Project into the current Team Project but I think this adds unnecessary complexity.

Thanks

 

Developer
Dec 16, 2010 at 1:49 PM
Edited Dec 16, 2010 at 1:57 PM

One option to consider, as you note above, in this scenario (Common Shared Code) is to branch from the Common Code Team Project into the Dependent Team Project(s).

Branch $\CommonTeamProject\Main -> $\DependentTeamProject\CommonCode

Note: this new branch in the dependent team project cannot be nested under any existing branch in the target team project. TFS 2010 does not allow nested branches.

Once you have branched the common code into your team project, add the project(s) to your solution and create project refererences in any dependent projects that reference the common code.

I have co-authored an article for MSDN magazine that talks about various approaches to sharing code. This is one of the approaches. Look for publication in early 2011 (The publishing lead time is frustratingly long).

One issue to consider when you consider whether to branch from one Team Project to another, is whether you want to be able to make changes in the common code from the dependent project, and have the ability to merge it back to the common code base (some do not want to allow this).

Another issue to consider is whether you want all dependent projects to use exactly the same version of source for the common code, or whether you will allow specialization in the dependent project. Branching from the common code team project into the dependent team project allows each dependent project to specialize the shared code (which may or may not be merged back).

It is also possible to setup workspace mappings to projects from different team projects. This might be a viable alternative to branching. Is this how you created the relative references you mentioned above?

Regards,
Bill Heys
VS ALM Ranger

Dec 16, 2010 at 2:33 PM
wheys wrote:
........

It is also possible to setup workspace mappings to projects from different team projects. This might be a viable alternative to branching. Is this how you created the relative references you mentioned above?

Bill,

Our temporary resolution while moving to\learning TFS (and proper branch/merging)  is as follows.

We have a $\CommonTeamProject\Main structure with the common project assemblies copied to the WorkspaceRoot\CommonTeamProject\binaries folder. Our $\DependentTeamProject projects reference the common assemblies from the WorkspaceRoot\CommonTeamProject\binaries.

This requires each developer to get and build the $\CommonTeamProject\Main locally prior to working on $\DependentTeamProject. We currently have no problems with having to manually get and build $\CommonTeamProject as we are a very small team and change to the common code is extremely infrequent. We then use assembly references as needed in our $\DependentTeamProject(s) to the WorkspaceRoot\CommonTeamProject\binaries folder. This works fine since we all only map the root '$' and let all children of $ map to the defaults.

Our problem then surfaces by the addition of the extra folder when branching from say $\DependentTeamProject\Main\Src to $\DependentTeamProject\DEV\R1\Src. We pondered branching of the $\CommonTeamProject\Main\Src -> $\DependentTeamProject\Common but again we see that as a complexity we do not need for common code that rarely changes.

Thanks

Mike

Developer
Dec 16, 2010 at 3:16 PM

Mike,

Thanks for clarifying. Your approach is sharing assembly references rather than project references. This is another approach with pros/cons we discuss in our upcoming MSDN article.

Regards,

Bill Heys
VS ALM Ranger
 

Developer
Dec 16, 2010 at 6:06 PM
mikeschellenberge wrote:
wheys wrote:
........

It is also possible to setup workspace mappings to projects from different team projects. This might be a viable alternative to branching. Is this how you created the relative references you mentioned above?

Bill,

Our temporary resolution while moving to\learning TFS (and proper branch/merging)  is as follows.

We have a $\CommonTeamProject\Main structure with the common project assemblies copied to the WorkspaceRoot\CommonTeamProject\binaries folder. Our $\DependentTeamProject projects reference the common assemblies from the WorkspaceRoot\CommonTeamProject\binaries.

This requires each developer to get and build the $\CommonTeamProject\Main locally prior to working on $\DependentTeamProject. We currently have no problems with having to manually get and build $\CommonTeamProject as we are a very small team and change to the common code is extremely infrequent. We then use assembly references as needed in our $\DependentTeamProject(s) to the WorkspaceRoot\CommonTeamProject\binaries folder. This works fine since we all only map the root '$' and let all children of $ map to the defaults.

Our problem then surfaces by the addition of the extra folder when branching from say $\DependentTeamProject\Main\Src to $\DependentTeamProject\DEV\R1\Src. We pondered branching of the $\CommonTeamProject\Main\Src -> $\DependentTeamProject\Common but again we see that as a complexity we do not need for common code that rarely changes.

Thanks

Mike

Mike,

Perhaps you could clarify some points for *our readers*

You mention a "problem then surfaces by the addition of the extra folder when branching from say $\DependentTeamProject\Main\Src to $\DependentTeamProject\DEV\R1\Src".

First, could you be more specific as to what the extra folder is? I assume you are referring to the $\CommonTeamProject\Binaries folder.

Second could you elaborate some on what problem you are seeing when branching the Dependent Team Project? I assume that the assembly reference is invalid when you branch (which may have been the initial issue in this thread)

Bill

Developer
Dec 16, 2010 at 6:43 PM

Mike,

Two comments on your approach.

1. For larger teams with many Team Project, some may find it cumbersome or objectionable to "map the root '$' and let all children of $ map to the defaults". This means that each developer has one and only workspace which maps ALL of the Team Projects to their local hard drive folders. There may be a lot of files copied down from the server on a Get Latest at the root leve. As an alternative to this, I recommend a more granular mapping of workspaces. For example, I might only map the specific Team Projects I am working on. I might also only map the specific branches within those team projects I am working on.

With respect to using assembly references with branching, one approach I recommend is to create a binaries folder *under* the Main branch. Rather than adding assembly references in the Dependent Team Project back to the binaries folder in the Common Team Project, I copy those binaries under tha Main branch (in the binaries folder). I create my assembly references to those assemblies. When I later branch Main to Dev, the binary folder under Main gets copied over as well. The assembly references remain valid. Just be sure that after you copy the DLLs into this binaries folder that you also add them to source control so they will be included in the branching/merging process.

Alternatively you can GAC these assemblies.

Regards,
Bill Heys
VS ALM Ranger