Quantcast
Channel: Version Control Guide (ex-Branching & Merging)
Viewing all 283 articles
Browse latest View live

New Post: Branch Scheme for Future Releases Using Reparenting

0
0
Under your original plan, Why would you ever merge release 2 or release three Into the main branch until release one is deployed into production?

Sent from my iPhone

On Dec 26, 2012, at 9:40 AM, LostArchitect <notifications@codeplex.com> wrote:

From: LostArchitect

Our development process includes simultaneous development on multiple release paths: while one team is working on the current major release another team is working on the next major and a third team may be work on the one after that. Of course the standard branches for ServicePack and HotFix work on the current production version also exist. Our problem is that we want to provide a simple merge path from main through all of the development branches. We are focusing on trying to (1) minimize the number of merges required for each check in and (2) protect main from becoming polluted with accidental merges from future release branches. The recommended advanced branching pattern suggests creating all of the future release branches at the same time with MAIN as the root:

MAIN
|- RELEASE_1
|- RELEASE_2
|- RELEASE_3

My primary issue with this scheme is that changes checked into RELEASE_1 then have to be merged forward into RELEASE_2 and RELEASE_3 through MAIN. It quickly becomes difficult to track what items haven't been merged forward and to which branches. Plus it is difficult to protect MAIN from accidental reverse integration merges from RELEASE_2 and RELEASE_3 while RELEASE_1 is still active.

I am proposing a modified hierarchical branch structure where RELEASE_2 is a child of RELEASE_1 and RELEASE_3 is a child of RELEASE_2.

MAIN
|- RELEASE_1
|- RELEASE_2
|- RELEASE_3

Then as each version is released to production, its child branches could be reparented to MAIN and that branch could be locked to prevent further checkins. This allows for a straightforward, sequential merge path and gives us the ability to protect main by denying reverse integration merges on all of the release branches. We can easily monitor what changes haven't been merged into the future releases (everything should always merge forward). By denying reverse integration merges on the release branches, we protect MAIN and ensure that it is only receiving changes from the current release branch. The only hiccup with this plan that I can see (and it seems minor to me) is that after reparenting, we will have to re-merge every change that was checked into RELEASE_2 back into MAIN. But as long as we manage our forward integration merges and make sure that the merge list is clear before performing the reparent, this should be a simple overwrite merge (any conflicts should have been resolved by the merge from RELEASE_1 -> RELEASE_2).

Thoughts? Comments? What am I missing?


New Post: Branch Scheme for Future Releases Using Reparenting

0
0

It shouldn't happen, but I'm trying to protect against accidents.  In my environment developers swap teams frequently.  A dev who was working on RELEASE_1 yesterday could easily be working on RELEASE_2 tomorrow.  Given that condition, I can easily foresee a situation where a dev get's confused and (thinking that he is working on the current release) accidentally performs a reverse integration merge from RELEASE_2 into MAIN effectively promoting code ahead of schedule.  My second scheme is focused on trying to prevent this.

New Post: Branch Scheme for Future Releases Using Reparenting

0
0
If they accidentally merge from rls 3 to rls 1, it will pollute rls 1 just as it would have polluted the main branch. Then when you go to merge rls 1, it has the release 3 stuff in it. I don't see what you gained.

The fact that you have 3 releases going on at one time is disturbing. Especially since you said some of the same people are working on multiple releases. This is highly inefficient. They could be more effective concentrating on finishing the first release. This parallelism provides the illusion of great activity. But it is actually a slower way to get results. There appear to be deeper issues here of release planning and program management. It might be useful to explore your broader problems rather than thinking this is just a branch design issue.

Sent from my iPhone

On Dec 26, 2012, at 11:22 AM, lostarchitect <notifications@codeplex.com> wrote:

From: lostarchitect

It shouldn't happen, but I'm trying to protect against accidents. In my environment developers swap teams frequently. A dev who was working on RELEASE_1 yesterday could easily be working on RELEASE_2 tomorrow. Given that condition, I can easily foresee a situation where a dev get's confused and (thinking that he is working on the current release) accidentally performs a reverse integration merge from RELEASE_2 into MAIN effectively promoting code ahead of schedule. My second scheme is focused on trying to prevent this.

New Post: Branch Scheme for Future Releases Using Reparenting

0
0

I addressed that possibility as well in my proposed scheme.  By denying the ability to perform reverse integration merges on the release branches we do not allow for the possibility of merging from RELEASE_3 into RELEASE_2 or RELEASE_2 into RELEASE_1.  This can be simply implemented with a custom check-in policy.  Putting a similar restriction on MAIN with a growing set of separate child branches would be more difficult.  The gains from this scheme are (repeated as listed above):

  1. A sequential merge path from 1 -> 2 -> 3 (as opposed to 1 -> Main, Main -> 2, Main -> 3)
    • This also guarantees that all changes from RELEASE_1 will get merged into future branches, rather than being left behind on the MAIN line and never merged forward
  2. Faster utilization of new features implemented in previous releases (available immediately upon forward integration merge)
  3. Identifying unmerged items for branches RELEASE_2 and RELEASE_3 is very simple (everything should always merge)
  4. It is easier to protect MAIN against accidental reverse integration merges from future release branches

In short, I believe that this offers greater synchronization between the branches with the least amount of effort for both the developers and the build master/TFS admin.

Project management is beyond the scope of the problem which I am addressing here.  I am trying to design a safe and efficient branching structure based on the development environment as it exists.  I believe that this scheme does that, but would appreciate any input that shows flaws in the design or gaps in my logic.

New Post: Branch Scheme for Future Releases Using Reparenting

0
0

Is there a possibility of two versions released at the same time?  I doubt that would happen.  A more managable approach would be to have one Service Pack branch off of main and branch your releases from Service Pack.  Any production bug fixes would be done in Service Pack and the new version would be branched off of there.  When you are ready to reverse integrate, it would be from Service Pack to Main and so on.  Any new development versions that are ready to be released are forward integrated from Main to SP and then an immediate branch from SP to Release_x.  Since one version is live at a time, there is little need for each Release branch to have its own SP or hotfix.

  • Main
    • SP
      • Release_1
      • Release_2
      • etc.

New Post: Proper TFS Project, seperate source control and seperate branching Usage Advice

0
0

There was  scenario that I do not see catered for, for projects before TFS, with other tools, we used to follow this method, can you perhaps help me out with some additional guidance.

I have a client, they have several product streams, and some of these products talk to each other, and some parts of some products only exist to supplement a single product, some service several products…

Our Example:

                      SharePoint front end

                      BizTalk Integration Layer

                                              External parties

                      SQL Database project central store, shared.

                      Other internal systems

 

Firstly we run multiple projects at once, with multiple teams.

We have source code for the various systems, they do interact with each other, some not all, and the integration layer between is considered a separate system, as we use an ESB concept where all interfaces are re-usable, as we do often 80% of the time re-use them.

 

We have source code repository for these streams:    

Root

\SharePoint

\BizTalk

\Database(special name)

\Internal system1

\Internal system2

 

Leaving aside from the branches, for main, dev, test and uat, and the whole management of branches for the moment…

 

We will have a project…..

                      It will take branches from SOME, never all of the streams of source code.

 

Here is where it gets interesting…..

 

What we used to do, was make a team project in TFS for the project, because we can use the same source code, and take branches into our new TFS project, we take a branch of main into our TFS project for the Streams in this project.

Two interesting parts:

We may have another project….. That shares some of the same parts not all of the source code for the streams.

We may have another phase of an existing project we want to kick off, usually before the previous one has finished.

 

The guidance indicates a single TFS team project per product, however we have a few products but there are MANY projects that cover some of these products.

Do we create team projects for each of our projects, and then new phase of the same project occur in the same team project and can be identified by a separate branch, and work items with a different area or iteration…..??

 

Our team projects have 30 – 40 releases over a 5 year period, and eventually touch most of the source base of all product streams, loads of work items/stories/bugs, iterations, quite massive..... and I do not want to to be extremely messy... .

We have NEW projects that do not touch SharePoint, and are integration only projects that touch a couple of systems (no code in these systems, or external systems) would these be created as separate TFS projects, and branching of the source code done.?? Is this valid?

My biggest problem with TFS has always been the weird way the source code and the team projects are tied together so tightly…. A project can cover code from lots of projects, do you create a master main team project that’s just for source code storage, and is always branched from, with a main branch and maybe has the release branch.

I would hope someone has come across this before and I’m not alone here…. I’ve documented much of this, and it went along the lines of your branching guide, but took it further…. What I’m looking for is the best practice, as I have a client that has not start down this route already and is NOT willing to fix their mistakes…. They are about to go TFS 2012 and re-structure their entire TFS as they have gone down a totally wrong route.

Can some TFS people please help with the detail so we can get it right, I'll publish the results for all, freely, once its done.

New Post: Proper TFS Project, seperate source control and seperate branching Usage Advice

0
0
I don't know what "best practices" are. I'll let someone else speak to that. But the last two places I used TFS, we used one single TFS Project to store all source control for our main products. And we ran all our projects out of that one TFS project. So all work items were comingled in one TFS project. We kept projects separate by using Iterations. Here is an example Iteration tree
-Projects
----2012
----2013
-------Project A
-------Project B

And we used the Area to designate different products.

IMHO, TFS would fit our world better if it could make its source control container more loosely coupled to the work item container, to represent that SOFTWARE PRODUCTS are not PROJECTS. Then we could have one source control container for every major software product. And one project container for every major work effort. Then if you could somehow link a project container to multiple product containers, we could check in changes to various products as part of a single task in the project.




On Wed, Jan 16, 2013 at 5:00 PM, PaulSomers <notifications@codeplex.com> wrote:

From: PaulSomers

There was scenario that I do not see catered for, for projects before TFS, with other tools, we used to follow this method, can you perhaps help me out with some additional guidance.

I have a client, they have several product streams, and some of these products talk to each other, and some parts of some products only exist to supplement a single product, some service several products…

Our Example:

SharePoint front end

BizTalk Integration Layer

External parties

SQL Database project central store, shared.

Other internal systems

Firstly we run multiple projects at once, with multiple teams.

We have source code for the various systems, they do interact with each other, some not all, and the integration layer between is considered a separate system, as we use an ESB concept where all interfaces are re-usable, as we do often 80% of the time re-use them.

We have source code repository for these streams:

Root

\SharePoint

\BizTalk

\Database(special name)

\Internal system1

\Internal system2

Leaving aside from the branches, for main, dev, test and uat, and the whole management of branches for the moment…

We will have a project…..

It will take branches from SOME, never all of the streams of source code.

Here is where it gets interesting…..

What we used to do, was make a team project in TFS for the project, because we can use the same source code, and take branches into our new TFS project, we take a branch of main into our TFS project for the Streams in this project.

Two interesting parts:

We may have another project….. That shares some of the same parts not all of the source code for the streams.

We may have another phase of an existing project we want to kick off, usually before the previous one has finished.

The guidance indicates a single TFS team project per product, however we have a few products but there are MANY projects that cover some of these products.

Do we create team projects for each of our projects, and then new phase of the same project occur in the same team project and can be identified by a separate branch, and work items with a different area or iteration…..??

Our team projects have 30 – 40 releases over a 5 year period, and eventually touch most of the source base of all product streams, loads of work items/stories/bugs, iterations, quite massive..... and I do not want to to be extremely messy... .

We have NEW projects that do not touch SharePoint, and are integration only projects that touch a couple of systems (no code in these systems, or external systems) would these be created as separate TFS projects, and branching of the source code done.?? Is this valid?

My biggest problem with TFS has always been the weird way the source code and the team projects are tied together so tightly…. A project can cover code from lots of projects, do you create a master main team project that’s just for source code storage, and is always branched from, with a main branch and maybe has the release branch.

I would hope someone has come across this before and I’m not alone here…. I’ve documented much of this, and it went along the lines of your branching guide, but took it further…. What I’m looking for is the best practice, as I have a client that has not start down this route already and is NOT willing to fix their mistakes…. They are about to go TFS 2012 and re-structure their entire TFS as they have gone down a totally wrong route.

Can some TFS people please help with the detail so we can get it right, I'll publish the results for all, freely, once its done.

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online atcodeplex.com




--
David Kreth Allen
612-374-1119

New Post: Proper TFS Project, seperate source control and seperate branching Usage Advice

0
0

A few questions to clarification:

  1. What do you mean with Streams?
    Not sure we are following...
  2. What is your definition of  a project?
    If we use Visual Studio as an analogy, is your project Visual Studio or IntelliTrace, Architecture Tooling, etc.? The definition will help us walk through the planning guide and determine the team project collection and team project structure.
  3. Where in the guidance are we recommending a single Team project per project?
    We do not recommend that and typically recommend less (single) team projects containing multiple products/projects segregated using areas or in TFS 2012 Teams. Seehttp://vsarPlanningGuide.codeplex.com which discusses the team project collection and team project question of one or many. Also see ourdogfoodingblog series in which we are sharing our objective to consolidate from many to one Team project, our experiences and challenges.
  4. Why does the code sharing guidance in the latest http://vsarbranchingguide.codeplex.com guide not suit you?
  5. Why are you saying that source code is tightly coupled to a team project?
    I need to mull over this and your response, because I feel it is loosely coupled to a team project and tightly coupled to a team project collection.

At this stage I am leaning towards a release or feature branch scenario, using code sharing, a single Team Project and implementing branch when and as needed. Start simple and avoid complexity at all cost ... it is easy to create a complex branching environment, but a nightmare to merge.


New Post: Proper TFS Project, seperate source control and seperate branching Usage Advice

0
0
I'm glad you posted this reply. I had a serious misconception that I cleared up. I thought that I had to have all my work initiatives ("Projects" in the business sense) share a single TFS Team Project in order to operate on a shared code base. After reading your message, I did an experiment on TFS 2012 and TFS 2010, and discovered what you already knew: I could create a separate TFS Project for every business project, yet still have source code in one place. Or even go so far as to have a many-to-many relationship between TFS projects with their source code assets and the TFS Projects with work items.

I don't know where I learned that incorrect assumption. Was it a limitation from an earlier version of TFS perhaps? I remember being frustrated long ago because I wanted to create a new TFS project for a new business project, so we could use a different Project Workflow template.

Anyway, I posted it so others who may have my misconception may see the opportunity.

Also, I did not know the "ADVANCED VERSION CONTROL GUIDE" existed. It's a nice resource. Thanks for mentioning it.

On Wed, Jan 16, 2013 at 10:39 PM, wschaub <notifications@codeplex.com> wrote:

From: wschaub

A few questions to clarification:

  1. What do you mean with Streams?
    Not sure we are following...
  2. What is your definition of a project?
    If we use Visual Studio as an analogy, is your project Visual Studio or IntelliTrace, Architecture Tooling, etc.? The definition will help us walk through the planning guide and determine the team project collection and team project structure.
  3. Where in the guidance are we recommending a single Team project per project?
    We do not recommend that and typically recommend less (single) team projects containing multiple products/projects segregated using areas or in TFS 2012 Teams. Seehttp://vsarPlanningGuide.codeplex.com which discusses the team project collection and team project question of one or many. Also see our dogfooding blog series in which we are sharing our objective to consolidate from many to one Team project, our experiences and challenges.
  4. Why does the code sharing guidance in the latest http://vsarbranchingguide.codeplex.com guide not suit you?
  5. Why are you saying that source code is tightly coupled to a team project?
    I need to mull over this and your response, because I feel it is loosely coupled to a team project and tightly coupled to a team project collection.

At this stage I am leaning towards a release or feature branch scenario, using code sharing, a single Team Project and implementing branch when and as needed. Start simple and avoid complexity at all cost ... it is easy to create a complex branching environment, but a nightmare to merge.

Read the full discussion online.

To add a post to this discussion, reply to this email (vsarbranchingguide@discussions.codeplex.com)

To start a new discussion for this project, email vsarbranchingguide@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online atcodeplex.com




--
David Kreth Allen
612-374-1119

New Post: Reparenting question in VS2012

0
0

If I reparent a branch to have no parent, should VS2012 display its original parent as a possible target branch in the merge wizard?

It does and I didn't expect that, if it had truly been reparented to the root of the collection, ie. have no parent, it would show any possible target branches to merge to.

Am I misunderstanding something here?

 

Thanks,

Warwick Baker.

New Post: Feature Branch plan and Automated Builds

0
0
After studying the branching guide, I've come to the conclusion that the Feature Branch plan would work the best for our team.

I'd like to make this as easy as possible for the devs on my team, so I'm looking for a way to set up a build definition that will build and deploy our web app to a test location for the currently open solution. I seem to be stuck because the build definition requires a solution file in "Projects to Build", and this would be changing for every branch.

Is there any way to configure the build process to build the currently open solution?

New Post: Feature Branch plan and Automated Builds

0
0
You will want a separate team build definition per branch there, and they may all use the same build process template that does the workflow you describe. I think there is some confusion here as you are not really interested in building a solution that is open on a developer's machine, but rather what is stored in version control (your real "version of the truth").

I think we are headed down the wrong path to worry about what solution is open on a devs machine, etc.

New Post: Feature Branch plan and Automated Builds

0
0
I'm confused. Spivonious, how many people are on your team? And what do you mean by "currently open solution?"

New Post: Feature Branch plan and Automated Builds

0
0
I was hoping to not have to make two new build definitions for each branch, as these branches can and will be very temporary (sometimes only lasting a few days).

Ideally ,our workflow would go like this:
  1. dev team 1 makes a new branch from main and begins work on their feature.
  2. dev team 2 makes a new branch from main and begins work on their feature.
  3. dev team 2 finishes and is ready for testing. They build their branch to a test environment.
  4. dev team 2 testing passes, changes checked into main, main is built to production.
  5. dev team 1 merges main into their branch to get dev team 2's changes.
  6. dev team 1 ready for testing, build their branch to test enviroment.
  7. dev team 1 testing passes, changes checked into main, main is built to production.
I would absolutely love to have a build definition that both dev team 1 and dev team 2 could use to put their branch into a test environment. Something where the teams could choose the solution to build (from source control, not locally) at the time the build is queued. Is this possible without developing a custom add-in?

Oh, and our entire department is six devs, one designer, and two report writers. We have a couple of large projects that routinely have independent changes going on concurrently.

New Post: Feature Branch plan and Automated Builds

0
0
I'm starting to think that having a build definition on a feature branch isn't worth anything. Test builds can happen from Main, and another branch can be added to handle releases. Main builds to test on check-in and Release builds to prod on check-in. Devs can setup build definitions to Dev if they want to, but it wouldn't be required. If we find that we really need that build to Dev, we could always add another branch in between Main and the features.

Anything I'm missing?

New Post: Feature Branch plan and Automated Builds

0
0
It depends what your quality bar is for the main branch. If, as in most cases, it contains the latest stable"version of the truth" you need at worst a gated check-in build, or separate the main and feature branches with an integration branch which has a build, or define a build per branch. Personally I prefer to keep main in a known and stable state, defining builds per dev and/or feature branch.

New Post: Feature Branch plan and Automated Builds

0
0
Yes, we'll need to figure out what "stable" means for us. I'm leaning towards "feature completed and ready for testing". We'd just need to be careful to only merge the changeset from the feature branch into the release branch.

Thanks for the input, everyone.

New Post: Branching Strategy - (dev, qa, uat, stage) to Branch Per Release

0
0
Hi Bill-

I do love the simplicity of the strategy but i have a couple of questions I'm hoping you can help me with.

After you deploy from DEV to QA or UAT, where do you start working on your next round of DEV changes? Because, what if there are necessary changes to the UAT code? Since there is no UAT branch, where would you do the changes so that they don't get jumbled with the next round of DEV? Same goes for changes to RELEASE for emergency bug fixes but I assume that in this case you manually write the changes into RELEASE and into DEV.

We have a single release web site for our customers. We do QA/UAT before releasing updates. We do separate DEV while code is in QA/UAT. My plan may involve a service branch but we may just do fixes in the RELEASE branch.

A little bit of guidance here would be a huge help and much appreciated.

New Post: Branch to share assemblies and other blobs between team projects?

0
0
Is branching a good or even the best way to share assemblies, libraries and other blob assets between different team projects?

I don't recall seeing this use case covered in the ranger guide.

There is an option that is not super well documented:
  • Immediately convert source folder to branch (enabled visualizations)
It is the default but I'm not sure if it is relevant for blob assets.

New Post: Branch to share assemblies and other blobs between team projects?

0
0
Hi John,

Take a look at the "Advanced Version Control Guide" document. There is a section titled "Dependency Management Patterns". It goes through different scenarios of sharing source code, binaries, and 3rd party libraries.

Branching vs Not branching comes down to how often the libraries and blob assets change. If they don't change that often, you may just want to create a folder for each version and reference or update them when needed. You need to create a dedicated team project for you shared assets.

Let me know if you need more info.

Cheers,
Ahmed
Viewing all 283 articles
Browse latest View live




Latest Images