Setting up new projects and branch designs in TFS 2015. This detail may be significant - I'm using it for PowerBuilder projects, not .NET - VS2015 is used to set up branches and perform merges, the files themselves will be checked in and out in PowerBuilder. Far as I can see that shouldn't make a difference, but mentioning it in case I've missed something
Using the following sample layout:
Prod branches to/from Mod, down to Dev. New CO projects branch from Prod (so they always start with a fresh set of the latest live code), then merged (via baseless merge) to the DEV branch, and re-parented once the connection is set up. That way the users wouldn't have to remember to do a baseless merge; Dev will become the default merge target
Merges would them go back up from Dev to Mod, then back to Prod
The issue is that as a test, I tried the baseless merge after the branch, expecting no files to be merged, as nothing has changed yet in any branch. But the merge from the CO branch to Dev merged ALL files. Not an issue now since there's no changes in place, but would be quite a problem once several projects have been merged to DEV.
After that merge, I made a small change in the project and tried a merge; only the one changed file merged.
My best guess is that since the new CO branch was created after the Dev Branch, it was seen as everything in it is newer than the Dev branch, so it rolled over everything. Not sure how it would treat changes in Dev not seen in the Prod branch yet, haven't tested that scenario. It SHOULD at the very least tell me there's changes that I need to merge, but I fear it might just roll over them with the "new" files in the CO branch.
The question is, how can/do I tell the system that this new branch is "not newer" than the Dev branch? Does indeed the fact that these are PowerBuilder files somehow limit the ability of TFS of recognizing versioning in some way?
Or even more simply, is the branch layout I'm trying not the best method?
EDIT - here's the structure I'm currently using for my .NET projects - I was trying to use the layout above instead for the new code.
It uses the "Main" branch suggested below in the comments, but since I'm pulling "CO Branches" from Dev, I get code currently being tested, and not pristine Prod code. I'm assuming trying to branch and re-parent from Prod in this layout would result in the same scenario.
So is this the better way to go after all?
You may have a Main branch, which is the junction branch between development and release branches, representing a stable snapshot of the product.
You can branch from Main to Dev, Mod and Prod, when the work on Dev branch finished, merge from Dev to Main, when you want to release the product, merge from Main to Prod. So when you want to branch from the latest live code, you can branch from Main. In this way, you can merge from CO to Main, then Main to Dev or Main to Prod. All changesets will be reserved.
Related
In TFS 2013 how can I overwrite all folders and files under a specific folder with data from another branch?
I have a main and two dev branches and different functionality has been added to the same solution in both dev branches. Main is in sync with one dev branch. Now all functionality that has been added to the dev branch which is not in sync is now obsolete and I want to sync the solution in this branch with whats in main. As the solution differs alot between main and the obsolete branch a traditional merge wont work.
Why not just delete the branch (or rename it for archive purposes), and create a new branch off MAIN?
Another option is to rollback all changesets in the Obsolete-Dev branches history, then do a merge from MAIN.
When should one branch/tag in Mercurial (hg), both at the local repo level and at the centralized/originating repo (that you hg clone)? When should you merge (again at the local level and in the central repo)?
I come from a SVN background where branches were used for new features ("feature branches"), as well as "release branches". In the case of feature branches, a developer would create a branch if he/she knew a project was going to span multiple sprints/releases. The feature branch would then be merged back in once the developer was certain they'd be releasing the new feature during the given sprint. The release branch would then be created and deployed to QA and a staging environemnt for QAT/UAT testing respectively. Any bugs that arose during testing would be committed directly to the release branch. When the release branch was finally ready to be released, it would be tagged (for archival/record-keeping purposes) and then finally, after the release branch was deployed live, it would be merged back with trunk.
How does this process change with a DVCS such as hg?
Branching|merging policy can does not differ at all. These processes just give less headache in Mercurial (you will not be a victim of "Refactoring Hell" with a minimal level of accuracy, unfamous Tree Conflicts are also history) - DVCS vs CVCS will change almost nothing here, Mercurial give you just more freedom: branch when|if you want
Me and my friend are two days into using Git now but we still lack the know-how to use it properly and utilize its full power though it is a tremendous step in the right direction, compared to using Facebook messages to sending and syncing files. We have searched over the net and most of the guides for Egit either assume you work alone or that someone else clones and branches off to their own repo. However we are collaborating on the same project (a 2D RPG) and don't know how to properly use Egit to work together. Some of the problems we face:
1. We had the exact same copy of the project, he changed some of the methods we used, I changed some of the classes and resources we use. He committed and pushed to repo first. Now I cannot push or commit or even pull because of conflicts in the files (repo vs local) which Egit complains must be resolved.
2. How do you properly synchronize code that you are collaborating on? Lets say either one of us is first out to push to repo, what must the other (the puller) do to make sure his own code is not completely overwritten, only accept parts that have changed, parts that we think should be changed.
3. Do we always have to make a (new) local branch, pull to this, see changes, and merge the changes we want with the master/main? How do you properly do this.
Any input is most welcome, we are already much more efficient with our broken knowledge, more will only do good :)
Ok here are my answers:
We had the exact same copy ... because of conflicts in the files (repo vs local) which Egit complains must be resolved.
First you should make sure you use separate branches so that you can always commit.
Then you have to resolve any conflicts when you merge.
How do you properly synchronize code ...
Use separate branches to make sure code is ok before you pull it into master branch.
Do we always have to make a (new) local branch ...
Yes, git is built on the assumption that this is the best way to work. "Everything is local"
This is the way I or we usually use branches:
Main dev branch (Master)
Project branch, used to merge in features added by this project. When all features have been added and seems to work this is pushed/merged into the master branch.
Developer branches, every developer has his/her own branch to develop a specific feature before pushing/merging that into the project branch.
What could sometimes be good to have is also specific release branches. I.e. when a project has merged all added features into the master branch and everything seems ok, a release branch is created for regression testing. This branch will eventually contain the released software when all testing has been done.
The benefit of doing a separate release branch is that the main branch can continue to be developed, but if a fast bugfix has to be done on an earlier release it can be done on that release branch and then later merged into the master branch.
//jk
I am new to version control. I often hear these words Merging and Branching. I also see different developers working in different branches.
Can someone explain the flow on this. What is the difference between Merging and Branching. When to go for Merging and Branching
Branching is about isolating a development effort in a specific history, parallel to the main one.
See "When should you branch?": you branch when you cannot commit on the current branch (because it would break the work of your colleagues)
Merging is about reconciling two different branches.
You merge when you want to take into account in your branch the changes of the other branch you need to merge.
The workflow depends on the tools.
SVN offers either merge-based development or trunk-based development.
Tools with easier branching capabilities (like Git for instance) offer a workflow based on the various development lifecycle steps:
In the concept of git,
Branch is just a pointer to a commit, and will be advanced to the new commit when you make new commit to that branch.
Git has 2 types of branches: local and remote.
git can merge any single commit, not only the head of a branch.
I take the most simple merging workflow as an example.
2 developers are working on a project.
They are working independently based on the same version.
They share the master (main) branch via a server when they complete.
The first developer commit changes and push to the remote branch first. The second developer then synchronizes the changes by pulling changes made by the first developer.
A merge commit will be automatically created.
Our dev team works inside existing projects, and deploys on completely separate environments. The work we do is not never expected to be merged back into theirs, but we are required to stay in line with them. They use the traditional trunk-branch (but not really tags) setup. A branch is created for a production release, and then development continues on it as they release.
The way our team does it, we copy their release branches to our own trunk (initially), which itself contains trunk/branches/tags. During development we are on trunk, and tagging for production releases. When we update from their latest release, its often impossible to do a straight merge from that branch to our trunk. It seems much cleaner and trouble-free to start with their branch, merge in our work, and eventually rename it to trunk.
All of a sudden I feel like a subversion dummy text generator...
Given the constraint that we can't change the other team's workflow, is there a better flow for us? Let me know if I'm missing something in the explanation too.
thanks.
Two main principles:
Vendor branches
Merge often
Due to ignorance of rule 2 you get "Merge hell" as expected
For more reasonable workflow (read about Vendor branches in Net, it has a lot of information) you can
Not just copy upstream branch to your trunk, but create vendor-branch (branch) in your repo, link it with svn:externals to source branch (without fixing source-revision in URL, link to moveable HEAD)
Copy branch to (empty) trunk
Monitor commits into upstream repo (SVNMonitor, CommitMonitor) and on every commit to upstream branch merge your vendor-branch with your trunk (svn 1.6-1.7 will be better than older versions)
After finishing upstream brach and starting new you can or edit externals definition in old branch (for next branch URL) or delete branch completely and start new (deleting all from your trunk not needed, only merge from new branch content)