Should shared projects be branched?

Question

I am wondering what is a best practice for sharing project code. We have a few projects that are used in multiple solutions.
Should we use branching, creating release dlls or referencing shared projects directly?

Reading a previously posted message [http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=525206&SiteID=1] about sharing project code two methods are suggested: branching and referencing shared projects directly.

In the past we have referenced shared projects directly but when branching, relative paths no longer work and we have to manually fix references creating changes we don't want to be propagated to our main branch. This makes me wonder if referencing shared projects directly is such a good way.

I find branching to be a logical way to go for my team as we want isolation from everyone else. But here comes the problem. What happens with reocurring dependencies? When Project X (PX) depends upon "Shared Project A" (SPA) as well as "Shared Project B" (SPB) which depends on SPA. In this scenario I would have branched SPA and SPB into PX -  SPA would however also have been branched into SPB hence there are now two SPA branches.

PX
+Shared
  |
  +---SPA
  |
  +---SPB
       |
       +---SPA'

In the solution file for PX what SPA should be referenced - SPA or SPA'? As only one of them can be referenced would I have to merge SPA' into SPA and change the references from SPB accordingly? This would mean that the SPB branch contains changes we don't want merged to the SPB main branch.

I have read TFSGuide as well as well as the branching guides suggested in previous posts about branching but none have answers to this particular problem.

Is creating release dlls for sharing a bad idea?

I would very much appreciate if anyone has any suggestions on how to handle this scenario efficiently as everything seems to have a downside to it.

Thanks in advance,
B

Answer 1

Is there simply no one that has experienced anything related to this scenario?


Hoping someone sees this.
Regards,
Babar

Answer 2

I don't understand the issue.  Why are relative paths breaking?  As long as you propagate renames/moves to other branches all at once, nothing should break.  In the other model, why would you need to branch a 2nd copy?

Answer 3

Dear Richard thanks for your answer.

I am new to branching and I may not be using the correct terminology but what I am seeing is dependencies becoming recursive ..

In this case my project PX depends on two projects: Shared Project A (SPA) and Shared Project B (SPB). SPB depends on SPA. In my case SPA is really a common utilities project.

When I set up SPB I branched SPA into SPB/Main/Source/SharedCode/SPA-Branch.

Now when I set up PX I branched SPA into PX/Main/Source/SharedCode/SPA-Branch and I branched SPB into PX/Main/Source/SharedCode/SPB-Branch.

What I have now are two branches of SPA:

PX/Main/Source/SharedCode/SPA-Branch
PX/Main/Source/SharedCode/SPB-Branch/SharedCode/SPA-Branch

Is this a wrong way to do it? In the SPB-Branch if I start referencing PX/Main/Source/SharedCode/SPA-Branch I may not have the same functionality as in PX/Main/Source/SharedCode/SPB-Branch/SharedCode/SPA-Branch.


What would be a solution to this problem?

Answer 4

Relative paths are not breaking and I am not doing renames or moves I simply have multiple branches of the same shared project as it is being used in other shared projects. And as I only have one solution file I am having difficulties with how to handle this scenario as I there may be changes in any or all of the different branches of the shared project.

I think I explained in the previous reply to this post why I have a multiple branches of the same shared project.

I am quite lost and it seems that I am approaching this incorrectly.

Should I be creating release binaries of shared projects instead?

I would very much appreciate any input.

Thanks.

Answer 5

Your way seems very complicated.  I'm not sure it can work at all when there are multiple dependencies like you have now.

Here's what I would do:

$/TeamProject
    /Main
       /PX
           /NormalPXStuff
           /...
       /PY
           /...
       /Shared
              /SPA
              /SPB
    /Branch1 (branch of Main)
      /...same as above...
    /Branch2 (branch of Branch1)
      /...same as above...

Use relative paths to link the projects as necessary.  For example, PX would have a reference to "..\Shared\SPA\SPA.csproj".

As long as every branch has the same structure, relative paths won't break.

Answer 6

Ok I see what you are saying but the problem is really that PX, SPA and SPB are all part of different team projects.

Let me try and put this up in your structure

$/TeamProjectPx
    /Main
      /Source
         px.sln
         /Lib
         /Code
           /NormalPxStuff
         /Shared
           /SPA-Branch(Main)
           /SPB-Branch(Main)
$/TeamProjectSPA(CommonUtils)
    /Main
       /Source
         spa.sln
         /Lib
         /Code
            /NormalSPAStuff
$/TeamProjectSPB
     /Main
        /Source
         spb.sln
         /Lib
         /Code
             /NormalSPBStuff
          /Shared
             /SPA-Branch  
    
Problem arises in Px as there are Shared/SPA-Branch and Shared/SPB-Branch/Shared/SPA-Branch. Get it?

Answer 7

Hmm, that's more troublesome.  Two options as I see it:
(a) move SPA and SPB underneath PX\Main\Source so that they all have a common branch root
(b) use assembly references instead of project references.  That is, check in a copy of SPA.dll and SPB.dll somewhere under PX\Main

(a) is better when the common libraries are closely coupled and/or change frequently.  (b) is better when the libraries are more independent (perhaps owned by another team, or even a 3rd party company) and/or don't change very often.

Answer 8

 

Couldn't you create several workspaces and place the shared code on disk in multiple places? A copy of it in each solution. I thought I read this suggestion in the TFSGuide.