We branch our whole master branch in TFS, following a somewhat git-like paradigm rather than branching specific sub-folders.
I have one such branch, for a feature. However this feature ended up really being two features, one dependent on the other. It's not possible to merge back to master yet, but I would like to keep the features separate so I can merge part A while I still work on part B.
Say I am working in branch A; is it fine to branch A to branch B, and then continue working on B? I would then merge A back to master in the near future, and then merge B into master later on.
I don't know if TFS has intelligence that could make this a problem if I want to merge master -> B later on, or if TFS is totally 'dumb' with tracking branches and doesn't care about such things.
In TFS 2012 merging has improved considerably. Among the improvements are the auto-merge engine, which reduces the number of conflicts and the baseless merge promotion to the UI.
In your case, when there's no merge relationship between two branches, a baseless merge should be performed. Once a branch relationship is established, subsequent merges will be normal.
For more details see the ALM Rangers Version Control Guide.
Related
At our company we use Perforce for our source control and version management. Currently we implement feature branching with the following "tree"
Hotfix01 - Hotfix branch
Hotfix02 - Hotfix branch
HotfixNN - Hotfix branch
Main (continuous trunk)
RC - Release Candidate branch (next release)
Working01 - Working branch, feature branch.
Working02 - Working branch, feature branch.
Working03 - Working branch, feature branch.
WorkingNN - Working branch, feature branch.
We setup the branches ahead of time. Not that this really matters. Branches off RC are feature branches. Right now we have >50 developers, Analysts and QA team members that are working individually or as a team on various projects, defect fixes, etc. When work comes in you find a free branch (we track that separately), claim that branch (e.g. Working56), do a force merge/sync from RC to that branch (to make sure it's exactly what's in RC at that moment), do your work (code, peer review, QA) while continuously merging any changes from RC to your working branch (at least once per day, perhaps more often as needed) and when you are done you copy the changes up to RC.
This works, but it means we have (at this time) 300 working branches to manage. We would like to implement feature branching in a more sane way where we would use branch mapping and such to create a branch as needed, named after what it's for and then once we merge it back to RC we want it to no longer show up in the depot forever (at least, not for every developer). Basically we want to see only those branches with active development as feature branches, hiding branches we are done with.
What is the best practice? Can this be done with perforce using either branches or streams? Are we missing something with Branch specifications that would allow this? Should we just not worry and allow thousands or tens of thousands of feature branches to pile up in the depot view under RC? Is the way we are doing it now the best we can hope for?
We've been using Perforce for 10 years and this is still a question that haunts us daily.
Task streams are designed for this.
https://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
Create the task stream, do your work in it, merge/copy back to the parent, then unload the task stream.
Common task stream gotchas:
Do not try to reuse or reparent them. One stream per task! If you try to reuse task streams their beneficial features mostly don't work but you still get all of the limitations.
The modified depot files live on after the task stream is unloaded. Adjust your mental model to use the list of streams as the source of truth for which streams are active, not the folders in the depot tree.
If you can handle those, task streams are hugely useful.
I was looking up good resources on branching strategies after doing feature branching for quite a few years and struggling with lots of branches and merge nightmares. Feature branches did give us a good isolation in managing releases in a pretty granular way as to which features should go to release. However, the problems they posed (many branches, merge conflicts) were way more than the benefits they gave.
We work with Oracle database (with 5000 objects) at back end. We also have multiple teams working on different areas of the same product. We are using Visual Studio with TFS (no DVCS).
The more branches we create, more database instances we require to give proper isolation in functional testing in those branches (each branch - one db instance) which are another set of problems.
We are adopting scrum and are searching for a branching model that will suit our release cycle (4 times a year) and CI builds. We are planning to do 5 regular sprint and 1 hardening sprint for each release.
From a feature branching model, we reworked our branching model to a very simple branching like below -
Development branch is working as our "Trunk" (for Trunk Based Development) and ALL developers (all teams) are committing to this branch (for quarterly release), testers are testing in this branch and CI server (Jenkins) is building this branch daily. We just need a clean MAIN at any time for safety as "Single Source of Truth for Last Release" which come to our use often for several reasons.
Maintenance branch is our bug fixing branch (hotfix) and is released several times during the year (irrespective of quarterly release). We prefer not to work directly on the main branch as want to have a "clean" Main branch. We do not want to let code go to Main without "manual" / functional testing done. Once a bug fix release is done, code is merged from Maintenance -> Main -> Development to integrate the bug fixes into Development.
We typically do not require the "Release Branches" as suggested in TBD since we will be continuously doing the bug fixes in the Maintenance branch, release from Maintenance and then merge the changes to Main (and then Development). We maintain only "Last release" and in case previous Release fix is required we create an old release branch from Labels in Main.
Have we modified the Trunk Based Development to an extent that it would pose problems in future? What are your suggestions?
Refer:
http://paulhammant.com/2013/12/04/what_is_your_branching_model
http://paulhammant.com/2013/04/05/what-is-trunk-based-development/#comment-2765204723
You should make a maintence branch from the tag that was released, only if you encounter a bug. Actually that's a release branch, and it should be named for the release. Say rel_1.1. By the time you've pushed out release 1.2 and it is clear you're not going to roll back, delete rel_1.1.
I have to maintain a base version of code and different "variations" of that code with client specific modifications for different clients sites.
It would be much easier to force all clients on the same variant, or have a super variant that encompasses all clients' needs. However that is not the nature of my world and I can't change it.
Given this environment, what is the best way to use github?
I can create a separate repository for each version. I can create one repository with separate branches. In either case I see how I can use github as a storage medium and version control for each variant, but I don't see how I can use github to help manage the code divergence.
thanks
Based on your question I would recommend a single repo, with a master branch. You can use other branches for the "variations".
The tricky part is when a commit is made to master that won't cleanly merge into another branch. You can do a merge commit with git merge, but I prefer to do a git rebase onto the new HEAD of master. This way people using master could easily pull in changes from that branch.
Related
I am trying to come up with a good branching merging strategy for a scenario when multiple features are being tested simultanously and at least one of them is not signed-off by stakeholders. I want to get the signed off changes pushed through to production with the least effort in terms of SCM operations and retesting.
I am using CVS (and I can't change this), but the question is SCM technology agnostic to certain extent.
Imagine that at any given time there are multiple features being developed on a common baseline. They're all worked on in isolation in their own branches. At some stage a build is pushed to test envrionment from the trunk that contains all the finished/tested and merged back to trunk changes. Let's say there are 5 branches merged in total and one is not good enough to pass testing or for some reason is not signed-off by the business.
If there was a silver bullet like 'unmerge' operation it would be perfect, but as far as I know there isn't.
My other idea is not to merge all the changes to trunk but to a separate branch forked off trunk and push a build off that branch to test server. If some change is withdrawn for any reason it would require forking a new branch off trunk and merging all but the withdrawn changes. Once all the changes are accepted this temporary branch can be merged to trunk.
I am wondering if this is not an overkill though.
Any other ideas?
While this doesn't really answer your question as asked, you might want to look into the concepts of feature toggles and "branch by abstraction" as discussed in Continuous Delivery. These are a couple of the core concepts that allow iterative mainline/trunk development.
Branching guidance usually describes an immortal "Main" branch, with features branched from Main, and merged back to Main, and Releases branched from Main, with further branches of a Release as necessary for Service Packs, RTMs, etc. The guidance regarding Main is often simplified to "no trash in Main."
I'm working with a group that releases regularly (as often as monthly) and serially. To them it seems unnecessary to ever return work to the Main branch. They use TFS 2010--diagramatically their branching structure looks like this:
Daily builds on a branch are made; eventually the branch goes to production. Any hotfixes to a branch are applied directly to that branch, and optionally merged forward to any future in-flight branches.
This group's branching strategy has been described perjoratively as the "Cascading Branches Antipattern." But is it really, given that these branches release to production, and then (usually) have a fairly short time to live?
Is this practice of cascading branches in TFS sustainable over the long term. If not, what are the limits, and when (after how many branches) might they be reached?
Is there any reason to NOT "destroy" Main, R1, R2 (etc.) eventually, or is there a "gotcha" that will prevent destroying and reclamation of space on the SQL server that is hosting the source code repository?
Cascading branches can work. I also can't think of any technical reason why destroying very old (preferrably archived) branches would impact the newer cascaded branches. Here are some issues to consider:
Developers have to map a new branch to their workspace after every release.
Developers have to manually move any work to a new branch if they weren't able to check it in before release (vs. just checking in to the same working Dev or Main branch after release.)
If you have one or more developers working in a child branch of Rn and a decision is made to move their work to Rn+1 then a baseless merge will be required to avoid checking into the original parent Rn branch.
MAKE SURE YOU SECURELY LOCK EACH BRANCH after release. All those branches will increase risk of a developer accidentally checking in a change to a released branch.
You need to adjust build definitions and any other path-specific artifacts after each cascade. If all development just works out of Dev (or Main) then the primary workspace and related build/project artifacts remain the same over time.
How do you work on a parallel features in isolation when you don't know which feature(s) will ship in Rn? (If you have a main branch the you can have multiple child feature dev branches from Main, then merge a feature branch only when it is stable and ready to merged to ship in the next release.)
I believe Jeff Levinson did a presentation that described branching evolution starting with single branch, then cascading branch, then Main+Release and a couple variations (while describing pros and cons of each). Check out Branching and Merging Practices - Jeff Levinson (Teched 2010 Video) (or related Branching & Merging PPT).
Enjoy! -Zephan