Here where I work we have a branch which is only used to check-in ongoing bugs and tasks. The small tasks are shelved and recovered in the next week, when they are checked-in.
We developed an auto-merge system where these small check-ins are all merged to all specific project Branches. Then, at the end of the project, it's reverse merged into the main branch, thus going automatically to another project branches.
But, suppose I have a branch with Feature A, and another with Feature B. I need a third, with both Feature A + Feature B + Bug Fixes. I don't want to reverse merge them as I don't want to mess up the main branch (yet)
I've created a branch from Feature A, and enabled my auto-merge from "Feature A" to "Feature A+B". So every bug fix goes this way: Main -> Feature A -> Feature A+B. And every checkin within Feature A goes to Feature A+B.
Now I want to do baseless merges from "Feature B" to "Feature
A+B".
Is there a way to enable merging between them (within TFS) ?
I know it blows hierarchy up, and I know I can just perform x baseless merges through tf.exe, or three-way merge the files manually (or using any known tool).
But I'm not responsible for doing this, it's another developer who got used to the Team Explorer interface and all, so it would make his life easier.
Now, now, I know a probable answer/comment will be:
"You need to revisit your branch structure, as something is wrong!"
If possible, put that with some tips, I'm currently trying to change that but I'm not sure what to do when we develop 2 separated projects that, all of a sudden, need to be put together.
Your assessment of the situation is correct, you will need to use a baseless merge here to establish a relationship between Feature B and Feature A+B. tbergstedt is correct that TFS will remember the merge relationship between the branches once it is established. So, that means you will only need to perform one baseless merge in this scenario and then the normal merge UI in Team Explorer will pick up subsequent changes.
Now, as far as actually performing the baseless merge goes, it will need to be done from tf.exe using the /baseless option UNLESS you have a Team Explorer 2012 Beta client. In Team Explorer 2012 we have added the ability to perform a baseless merge in the UI. If you don't have one, I would suggest that you just perform the first baseless merge and then left your co-worker do the subsequent merges using the UI.
-Taylor, TFS Version Control Development Lead.
As I understand it, once you have done a baseless merge between two branches using tf merge /baseless, TFS remembers this relation and from then on any user can perform a merge 'normally' between the two branches.
The catch is that the baseless merge probably will detect conflicts for every item, and you need to check in new versions of everything in order to create the relation between the branches for the items. So, using your branch structure and doing a baseless merge between FeatureB to Feature A+B, you must be very careful when solving the conflicts - if you simply select the target version, any FeatureA changes on the target branch will be overwritten with FeatureB!
I should add that I haven't done this all the way through; I had a similar scenario but bailed out when I realized that I needed to solve every conflict in detail. Our product is huge, so it wasn't worth the time and the risk for us.
Related
Keeps track of files in eclipse, who made changes on which branch
Hello Guys, I am using BitBucket for project management, and i Create different branches as per features. Multiple teams works on their own branches and some time multiple teams make changes in same file.
So at the time of release I have to merge all the created branches in one major branch, but at time of merge i get a lot of merge conflicts,
So basically what i want, when developer going to make changes in any file, dev will get to know all submitted changes in another branches for this same file, (where dev going to make changes), So he or she will know the possible scenarios.
An alternative is to ask for a developer to rebase his/her own branch on top of the main branch first.
Then you can merge that branch easily enough.
That way:
if there are any conflicts, they are detected and resolve by the developer (who knows best how to resolve it)
each merge is a trivial one.
I am new to Perforce and find it really hard to follow its workflow..
I have used Mercurial before (not in any advanced ways), but what I lack most in Perforce is the idea of named branches.
Let me explain what I'd like to do:
I get the latest revisions of all files and want to work on a new feature/story/task..
I create a brach, say "Feature 3021"
I code, save changes in this branch (hg commit)
I can save changes to a central server (hg push)
When I'm done coding, I merge the changes from "Feature 3021" with the main branch (default, master, etc.) - after that the main branch has the code I wrote
I can close the named brach ("Feature 3021") so that further commits are not possible.
I don't need this exact behavior in Perforce, but something analogous. I know that Perforce is centralized, so the commit-push step would be probably one, but this is a minor problem here.
All I care is to be able to save my work in version control at any time, even if it's not 100% ready - perhaps to a different branch. I'd also like other users to be able to be able to get my code (from this different branch), but only if they want this - the default branch should stay unafected as long as I don't merge my changes with it.
Is it possible? I am using Server 2012.2
Can you upgrade to Server 2013.1 or later? There's a great feature there, called Task Streams.
Here's some references:
http://www.perforce.com/blog/130627/task-streams-even-if-you-are-classic-perforce-shop
http://www.perforce.com/blog/130206/task-streams
http://www.perforce.com/perforce/doc.current/manuals/p4v/streams_task.html
The analogous flow in Perforce would be:
Maintain a main-line "branch" at some path, say //depot/default
To create a feature branch, integrate from //depot/default to //depot/feature-3021
Work under //depot/feature-3021 and submit
When you are ready to merge back, integrate //depot/feature-3021 to //depot/default
Regarding closing the branch after its use, there are a couple of options that I can think of. You could either change permissions or simply delete it. The delete could always be recovered.
Also note the paths don't need to be at the same hierarchy. A more reasonable branch strategy might use paths like this.
Main-line: //depot/default
Developer branches: //depot/dev/${user}/${feature}
I'm trying to identify the proper way of working with multiple branches on Gerrit that would match our workflow.
The way we work with branches right now is: we have master & feature branch. Master is the branch we want to polish and make it ready for release, while feature is obviously a field of intensive work. Now, in our particular case whenever somebody works on a bug fix, they:
create a change targeted for master branch
cherry pick it to the feature branch targeted change
once gerrit code review completes, submit both changes.
now the way i understand cherry-pick, it selects individual commit and merges it to the current change. if that is the case, i would expect to have no merge conflicts in the end, and indeed this workflow works perfectly with just GIT. Gerrit, however, most likely due to its nature (branches are not merged remotely the way these are locally and get a different sha tag) lists a tremendous number of conflicting files in the end.
Now, I resolved all these issues by applying merge strategy (ours on feature, theirs on master), but it does not feel right: if anything was not propagated, it just got discarded.
My question is: is there a safe workflow, similar to the above one, that would in the end produce a clean merge with gerrit?
I would say that it's better, in this case, to merge than to cherry pick.
A cherry pick adds the same changes but not the same commit. So while the source is the same on a cherry pick and merge the git tree is different. When the tree is different and you later do a merge git will think that the commit you previously cherry picked is missing and try to merge that change as well, even if the actual code is already there. That's probably why you get a lot of conflicts.
I would propose another way of working.
When you do normal work you develop on feature and push to Gerrit as normal.
When you do a patch (ie bug fix) on the stable production environment you do that directly on master (or local branches if you like but not on feature)
When the patch as been approved in Gerrit it get's merged into the real master and you can make a pull request to get that change to your local copy. Your version of master is now the same as Gerrits master
Now you would merge all new changes on master into feature. Make sure you do a rebase so that the patch ends up before anything you've already done on feature
Once it's time to deploy all new features you can merge feature into master, push to Gerrit (if you have permissions you can by pass gerrit by pushing directly to master instead of refs/for/master as these changes are already reviewed)
Once all changes are on Gerrits master you do a pull on your master and a merge into feature with rebase making feature a clean branch to work on. It's of course totally valid to have a new feature each release. Both work fine.
I'm a little confused, as this flow should work just fine. If other users submit changes before your bug fix is reviewed/verified/submitted, that could result in merge conflicts, but that should be rare.
If you:
Fix a bug on master
Push to review (creating change A in gerrit)
cherry-pick change A on top of the feature branch (resolving any conflicts from master to feature)
Push the cherry-picked change to review (creating change B)
Review/verify/submit changes A & B
Everything will work fine. The only way for merge conflicts to occur is if other users upload and submit changes between steps 1 and 5. Are you seeing different behavior? Can you provide more details?
Can anyone explain in plain English the difference between the two approaches? A link to a good clearly written tutorial would suffice also.
thank you.
They are not different approaches, but different sides to the same coin.
If you develop using branches, you need to merge them together eventually.
To answer the question:
A branch is a copy of a selected part of your source code, used for specific work (feature, project whatever).
A merge is the act of bringing two branches into sync and (normally) getting rid of one branch in the process.
From wikipedia, Revision control:
Branch
A set of files under version control may be branched or forked at a point in time so that, from that time forward, two copies of those files may develop at different speeds or in different ways independently of each other.
Merge
A merge or integration is an operation in which two sets of changes are applied to a file or set of files. Some sample scenarios are as follows:
A user, working on a set of files, updates or syncs their working copy with changes made, and checked into the repository, by other users.
A user tries to check-in files that have been updated by others since the files were checked out, and the revision control software automatically merges the files (typically, after prompting the user if it should proceed with the automatic merge, and in some cases only doing so if the merge can be clearly and reasonably resolved).
A set of files is branched, a problem that existed before the branching is fixed in one branch, and the fix is then merged into the other branch.
A branch is created, the code in the files is independently edited, and the updated branch is later incorporated into a single, unified trunk.
Branching is starting a new development line based on the state of the project where you branch from.
Merging is reporting changes from one development line or between development lines to another.
So clearly you need both at different points in time.
Links:
Branching / Merging primer from
microsoft
A more advanced site about source
code management
I don't think you can "oppose" merging vs. branching.
You branch when you want to isolate a development effort, as I explained in "When should you branch?".
The key question to ask, once you have a branch in which you (and other developers) can make evolution to (refactor? enhance? bugfix? ...), is:
"What should you do with the content of that branch?"
In other word, do you leave it alone, or do you re-integrate all its evolutions into another branch. And that is merging.
But merging alone isn't enough. What give merging its purpose is its workflow: from where to where are you merging your code?
Define your workflow, and you will really take advantage of what SCM is about.
In plain English, branching is like "the branch of a tree" where the tree is your software product and the branch is a special part of it that 'extends' from the center-column but has its own features.
In real life you make a branch of your software if you have to support two customers with slightly different whishes. You then have the core-product (A) and the customer-specific-product (B and C) which are basically the core-product with small changes.
Merging is taking this customer-specific branch (B or C), and re-integrating it with your core product (A). This is handy if you implemented a nice feature is branch B, that you'd like to have for everybody, so you merge it into the core product, A.
Is it possible to merge to a branch that is not a direct parent or child in TFS? I suspect that the answer is no as this is what I've experienced while using it. However, it seems that at certain times it would be really useful when there are different features being worked on that may have different approval cycles (ie. feature one might be approved before feature two). This becomes exceedingly difficult when we have production branches where we have to merge some feature into a previous branch so we can release before the next full version.
Our current branching strategy is to develop in the trunk (or mainline as we call it), and create a branch to stabilize and release to production. This branch can then be used to create hotfixes and other things while mainline can diverge for upcoming features.
What techniques can be used otherwise to mitigate a scenario such as the one(s) described above?
I agree with Harpreet that you may want to revisit how you you have setup you branching structure. However you if you really want to perform this type of merge you can through something called a baseless merge. It runs from the tfs command prompt,
Tf merge /baseless <<source path>> <<target path>> /recursive
Additional info about baseless merges can be found here
Also I found this document to be invaluable when constructing our tfs branching structure
Microsoft Team Foundation Server Branching Guidance
tf.exe merge /recursive /baseless $/TeamProject/SourceBranch $/TeamProject/TargetBranch
MSDN: How To: Perform a Baseless Merge in Visual Studio Team Foundation Server
You may want to revisit your branching strategy. How do you get production branches? Are you merging all code from development branches, regression testing and then creating a production branch for fixes? Or are you developing on the trunk and then creating production branches to stabilize and release from? The second way creates problems of the type you're describing. If you are using the first approach -- the trunk is supposed to be only for things that have been built on branches tested and then merged you will run into this much less often. Under that approach if you're still having this problem it may be because your development effort is very large and you may need a relatively complex branching strategy with layers of branching and promotion.
AFAIK you can do this as long as the branches were created off of the same original folder.
trunk/
branches/
-/feature1 (branched from trunk)
-/feature2 (branched from trunk)
If you do this then you should be able to merge between feature1 and feature2 as well.
Though my branching/merging experience with TFS leaves me wanting more. I wish we just had SVN.
Yes, you can do a baseless merge, but only from the command line (tf.exe).
TFS will allow you to merge with a branch that is not a parent/child - these are called baseless merges. See these links:
From MSDN
From the TFS Team via CodePlex
We typically do major or destabilizing changes on a development branch. If close to a major release of one of our products nearly all changes will be done on a branch.
I am far from a TFS expert, but I think you can merge siblings, and I think it is not a baseless merge.
We branched off our main branch (branch name "main") for a feature (branch name "feature"), then I needed some of the work in a branch that was also branched off the main branch (branch name "dev"). I would consider feature and dev branches to be siblings as they both came from the same parent. I merged feature to dev and all files (14000) were marked as merge, some were marked as merge,edit. I could not cancel (visual studio would just hang), so I accepted the merge. Then I merged dev to main, then I pulled main to feature, and again 14000 files were marked for merge. I was really upset, and afraid this would continue.
At this point we did a test project. We set up main, then branched dev and feature from main. We repeated the above steps with the same results. Once we completed the merge from main to feature, all future merges only showed the edited files.
After our little test I completed the merge from main to feature. And just like the test our merges now only show the edited files. We can go dev to feature, feature to main, main to dev, etc.
I did notice when branching all file dates were modified. Maybe this is an issue?