Sharing code between solutions in TFS [closed] The 2019 Stack Overflow Developer Survey Results Are InTFS 2010 Branch Across Team Projects - Best Practicestfs2013 share project across many projectsWhat is the difference between String and string in C#?TFS SourceControl Branching Merge From TrunkShowing which files have changed between two revisionsGit branch strategy for small dev teamForking vs. Branching in GitHubHandling multiple developers in one solution on TFSReSharper “Cannot resolve symbol” even when project buildsHow to fix TFS incorrect branchingFix Gilab error: “you are not allowed to push code to protected branches on this project”?How to merge bugfix branch to Master branch?
Can withdrawing asylum be illegal?
Why didn't the Event Horizon Telescope team mention Sagittarius A*?
! Package inputenc Error: Unicode character (U+2061) (inputenc) not set up for use with LaTeX
Using xargs with pdftk
Can we generate random numbers using irrational numbers like π and e?
What is the grammatical structure of "Il est de formation classique"?
How much of the clove should I use when using big garlic heads?
Compute the product of 3 dictionaries and concatenate keys and values
Why don't hard Brexiteers insist on a hard border to prevent illegal immigration after Brexit?
Straighten subgroup lattice
Is bread bad for ducks?
How to support a colleague who finds meetings extremely tiring?
Why isn't the circumferential light around the M87 black hole's event horizon symmetric?
Why doesn't UInt have a toDouble()?
Cooking pasta in a water boiler
Did the UK government pay "millions and millions of dollars" to try to snag Julian Assange?
How can I add encounters in the Lost Mine of Phandelver campaign without giving PCs too much XP?
$EDITOR environment variable won't set
Old scifi movie from the 50s or 60s with men in solid red uniforms who interrogate a spy from the past
If I score a critical hit on an 18 or higher, what are my chances of getting a critical hit if I roll 3d20?
Is an up-to-date browser secure on an out-of-date OS?
Falsification in Math vs Science
Why not take a picture of a closer black hole?
Why doesn't mkfifo with a mode of 1755 grant read permissions and sticky bit to the user?
Sharing code between solutions in TFS [closed]
The 2019 Stack Overflow Developer Survey Results Are InTFS 2010 Branch Across Team Projects - Best Practicestfs2013 share project across many projectsWhat is the difference between String and string in C#?TFS SourceControl Branching Merge From TrunkShowing which files have changed between two revisionsGit branch strategy for small dev teamForking vs. Branching in GitHubHandling multiple developers in one solution on TFSReSharper “Cannot resolve symbol” even when project buildsHow to fix TFS incorrect branchingFix Gilab error: “you are not allowed to push code to protected branches on this project”?How to merge bugfix branch to Master branch?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty height:90px;width:728px;box-sizing:border-box;
I have a few different applications that i need to share code between to reduce maintenance. I have tried to read a lot on stackoverflow and the web in general and it is a fairly common problem; i have not found an answer i like.
Our TFS branching structure is like this. We have three branches Development, Main and Production. On the Development branch all active development is done, when we are done with developing new features, we merge it with Main, and then to production. The production branch is always the code running on the servers. If we detect bugs that must be fixed before the next iteration. The changes are done in main, and merged with Production as we deploy. The applications that need to share code do not share a common branching hierarchy or a common iteration schedule. In fact one of the applications only go through a 1month iteration once a year. (I know this differs slightly from the conventional way of doing it.
During my research i have found a few different solutions, but i have problems with all of them.
Binary sharing:
One of the common ways i found was branching the compiled binary into the a folder beneath the development branch. My problem is that if we where to detect bugs in the shared code that must be fixed fast, the code in question is compiled. And if we where to fix the bugs we would get all the changes done to the shared code base.
Project sharing:
My main problem here is how it can be done in an acceptable manner. My initial idea was to when a new iteration started, merge the changes from the main branch with the shared code to update it. Merge the main with the development branch to update the development branch with changes as a result of bugfixing. And branch new updates version of the shared code into the development branch. But from what i understand this is not supported by TFS because i would create nested branches.
My question is:
How can i share a few common projects between solutions while keeping them in isolation and be able to fix bugs on the Main branch without worrying about the common projects having changed and therefor introducing new bugs. But still be able to fix bugs in the common project and merge those fixes back into the shared common projects.
c# tfs tfs2010 branch code-sharing
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
closed as off-topic by Sinto, JumpingJezza, AkshayNevrekar, Shiladitya, wscourge Mar 22 at 6:20
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Sinto, AkshayNevrekar, Shiladitya, wscourge
add a comment |
I have a few different applications that i need to share code between to reduce maintenance. I have tried to read a lot on stackoverflow and the web in general and it is a fairly common problem; i have not found an answer i like.
Our TFS branching structure is like this. We have three branches Development, Main and Production. On the Development branch all active development is done, when we are done with developing new features, we merge it with Main, and then to production. The production branch is always the code running on the servers. If we detect bugs that must be fixed before the next iteration. The changes are done in main, and merged with Production as we deploy. The applications that need to share code do not share a common branching hierarchy or a common iteration schedule. In fact one of the applications only go through a 1month iteration once a year. (I know this differs slightly from the conventional way of doing it.
During my research i have found a few different solutions, but i have problems with all of them.
Binary sharing:
One of the common ways i found was branching the compiled binary into the a folder beneath the development branch. My problem is that if we where to detect bugs in the shared code that must be fixed fast, the code in question is compiled. And if we where to fix the bugs we would get all the changes done to the shared code base.
Project sharing:
My main problem here is how it can be done in an acceptable manner. My initial idea was to when a new iteration started, merge the changes from the main branch with the shared code to update it. Merge the main with the development branch to update the development branch with changes as a result of bugfixing. And branch new updates version of the shared code into the development branch. But from what i understand this is not supported by TFS because i would create nested branches.
My question is:
How can i share a few common projects between solutions while keeping them in isolation and be able to fix bugs on the Main branch without worrying about the common projects having changed and therefor introducing new bugs. But still be able to fix bugs in the common project and merge those fixes back into the shared common projects.
c# tfs tfs2010 branch code-sharing
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
closed as off-topic by Sinto, JumpingJezza, AkshayNevrekar, Shiladitya, wscourge Mar 22 at 6:20
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Sinto, AkshayNevrekar, Shiladitya, wscourge
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
1
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13
add a comment |
I have a few different applications that i need to share code between to reduce maintenance. I have tried to read a lot on stackoverflow and the web in general and it is a fairly common problem; i have not found an answer i like.
Our TFS branching structure is like this. We have three branches Development, Main and Production. On the Development branch all active development is done, when we are done with developing new features, we merge it with Main, and then to production. The production branch is always the code running on the servers. If we detect bugs that must be fixed before the next iteration. The changes are done in main, and merged with Production as we deploy. The applications that need to share code do not share a common branching hierarchy or a common iteration schedule. In fact one of the applications only go through a 1month iteration once a year. (I know this differs slightly from the conventional way of doing it.
During my research i have found a few different solutions, but i have problems with all of them.
Binary sharing:
One of the common ways i found was branching the compiled binary into the a folder beneath the development branch. My problem is that if we where to detect bugs in the shared code that must be fixed fast, the code in question is compiled. And if we where to fix the bugs we would get all the changes done to the shared code base.
Project sharing:
My main problem here is how it can be done in an acceptable manner. My initial idea was to when a new iteration started, merge the changes from the main branch with the shared code to update it. Merge the main with the development branch to update the development branch with changes as a result of bugfixing. And branch new updates version of the shared code into the development branch. But from what i understand this is not supported by TFS because i would create nested branches.
My question is:
How can i share a few common projects between solutions while keeping them in isolation and be able to fix bugs on the Main branch without worrying about the common projects having changed and therefor introducing new bugs. But still be able to fix bugs in the common project and merge those fixes back into the shared common projects.
c# tfs tfs2010 branch code-sharing
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
I have a few different applications that i need to share code between to reduce maintenance. I have tried to read a lot on stackoverflow and the web in general and it is a fairly common problem; i have not found an answer i like.
Our TFS branching structure is like this. We have three branches Development, Main and Production. On the Development branch all active development is done, when we are done with developing new features, we merge it with Main, and then to production. The production branch is always the code running on the servers. If we detect bugs that must be fixed before the next iteration. The changes are done in main, and merged with Production as we deploy. The applications that need to share code do not share a common branching hierarchy or a common iteration schedule. In fact one of the applications only go through a 1month iteration once a year. (I know this differs slightly from the conventional way of doing it.
During my research i have found a few different solutions, but i have problems with all of them.
Binary sharing:
One of the common ways i found was branching the compiled binary into the a folder beneath the development branch. My problem is that if we where to detect bugs in the shared code that must be fixed fast, the code in question is compiled. And if we where to fix the bugs we would get all the changes done to the shared code base.
Project sharing:
My main problem here is how it can be done in an acceptable manner. My initial idea was to when a new iteration started, merge the changes from the main branch with the shared code to update it. Merge the main with the development branch to update the development branch with changes as a result of bugfixing. And branch new updates version of the shared code into the development branch. But from what i understand this is not supported by TFS because i would create nested branches.
My question is:
How can i share a few common projects between solutions while keeping them in isolation and be able to fix bugs on the Main branch without worrying about the common projects having changed and therefor introducing new bugs. But still be able to fix bugs in the common project and merge those fixes back into the shared common projects.
c# tfs tfs2010 branch code-sharing
c# tfs tfs2010 branch code-sharing
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
edited Jun 19 '12 at 7:09
user1450824
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
asked Jun 19 '12 at 6:11
user1450824user1450824
10037
10037
closed as off-topic by Sinto, JumpingJezza, AkshayNevrekar, Shiladitya, wscourge Mar 22 at 6:20
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Sinto, AkshayNevrekar, Shiladitya, wscourge
closed as off-topic by Sinto, JumpingJezza, AkshayNevrekar, Shiladitya, wscourge Mar 22 at 6:20
This question appears to be off-topic. The users who voted to close gave this specific reason:
- "Questions seeking debugging help ("why isn't this code working?") must include the desired behavior, a specific problem or error and the shortest code necessary to reproduce it in the question itself. Questions without a clear problem statement are not useful to other readers. See: How to create a Minimal, Complete, and Verifiable example." – Sinto, AkshayNevrekar, Shiladitya, wscourge
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
1
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13
add a comment |
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
1
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
1
1
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13
add a comment |
3 Answers
3
active
oldest
votes
What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.
Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.
However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.
Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.
So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.
Hope this helps.
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
add a comment |
Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.
edited May 23 '17 at 11:51
Community♦
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
add a comment |
Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.
What I ended up doing was both Binary sharing and code sharing
For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.
For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
add a comment |
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.
Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.
However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.
Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.
So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.
Hope this helps.
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
add a comment |
What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.
Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.
However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.
Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.
So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.
Hope this helps.
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
add a comment |
What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.
Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.
However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.
Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.
So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.
Hope this helps.
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
What I do is a version of what you called 'Binary sharing'. If you can think of your shared code as a 3rd party project, then you can apply the same rules for development that you would expect from a well run 3rd party project. That means that you should specifically version the shared code (with semVer or something similar) and maintain backwards compatibility wherever possible.
Yes, you are right, this means that if you find a bug in the shared code, you need to issue another version and then recompile the project that depends on this code.
However, it also means that if only one of the two projects dependent on the shared code needs the bug fix, only that project needs to take the new version.
Another benefit is that it is up to the project when to take the update. So you can manage the bug fixing process with more confidence.
So, to be clear, my suggestion would be to create a new TFS project for the shared code, give it all the love you would show to a 3rd party project (its own build, NuGet, etc), and then take a build assembly into a library folder for the projects that want to use it.
Hope this helps.
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
answered Jun 19 '12 at 8:38
Davin TryonDavin Tryon
53k9123116
53k9123116
add a comment |
add a comment |
Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.
edited May 23 '17 at 11:51
Community♦
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
add a comment |
Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.
edited May 23 '17 at 11:51
Community♦
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
add a comment |
Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.
edited May 23 '17 at 11:51
Community♦
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
Whilst the question isn't quite the same, I think that the answer maybe along the same lines as this one.
edited May 23 '17 at 11:51
Community♦
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
edited May 23 '17 at 11:51
Community♦
11
edited May 23 '17 at 11:51
Community♦
11
edited May 23 '17 at 11:51
Community♦
11
11
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
answered Jun 19 '12 at 15:08
James ReedJames Reed
12.2k4255
12.2k4255
add a comment |
add a comment |
Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.
What I ended up doing was both Binary sharing and code sharing
For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.
For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
add a comment |
Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.
What I ended up doing was both Binary sharing and code sharing
For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.
For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
add a comment |
Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.
What I ended up doing was both Binary sharing and code sharing
For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.
For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
Thank you everyone for all your help, because several of you contributed to my final solution iIhave chosen to post what I ended up doing here.
What I ended up doing was both Binary sharing and code sharing
For the projects that is often updated and with relatively fast iterations I referenced the shared projects I needed and created project guidelines to ensure that the code was backwards compatible for specific amount of time.
For the projects that was updated less frequently I branched in the compiled binary. I also created versioned the shared project and created guidelines to ensure that any backwards compatibility conflicting code resulted in an increment of the main component of the version number.
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
answered Jun 24 '12 at 11:19
user1450824user1450824
10037
10037
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
add a comment |
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
2
2
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
With your code sharing, how did you get around the nested branches issue?
– Carl
Aug 16 '12 at 11:46
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
@Carl ditto - how does this work since TFS can't nest branches? This would be my preferred solution if I could figure it out.
– Void Star
Jun 12 '17 at 23:09
add a comment |
I'm sorry - my english is bad :( :( but what is your question ? What do you want to ask ? You explain a lot about structure of your TFS (?) and branching and I lost you somewhere in the middle...
– Jasper
Jun 19 '12 at 6:53
Sorry i just got a little carried away, i appended a short version of the question now.
– user1450824
Jun 19 '12 at 7:10
What are you sharing as services / SOA might be a better approach. If you are sharing code libraries then perhaps try creating NuGet packages thus "sharing" the binary assemblies.
– Kane
Jun 19 '12 at 7:14
Im not talking about sharing the code to external users, but sharing code between different applications we are developing to reduce maintinence, code duplication, and create a common framework to build the different applicatons on top.
– user1450824
Jun 19 '12 at 7:23
1
Possible duplicate of TFS 2010 Branch Across Team Projects - Best Practices
– Kishan Vaishnav
Mar 22 at 4:13