Normally we develop our latest release in $/Project, and the branch never changes. When we release a version, we branch $/Project into $/Project-x.y and that becomes our maintenance branch. Changes from $/Project-x.y are easily merged back into $/Project.
Recently we created a real development branch, call it $/Project-z. $/Project-z has had a lot of changes that make it different from $/Project. However, periodically $/Project has been merged into $/Project-z. So far so good.
It is time to merge $/Project-z back into $/Project. Going through the Merge Wizard, we get an enormous pending change set including a zillion conflicts, many of which are the very changes that were merged from $/Project into $/Project-z.
Questions:
1) What in general is the best way to handle this development use case?
2) What should we do now?
3) Couldn't Vault be smarter about merging conflicts that are simply changes it previously merged from one branch to another?
Best practice for merging back to the main branch?
Moderator: SourceGear
During a run of Merge Branches wizard you can de-select any transactions in which the source code was already merged into the branch. The developers are looking into changing this in the future so that there's less of a hassle with is. I can add your "vote" to a change in that feature if you would like.
Problems merging branch back into main line project.
There are some big problems with this approach. The merge branches wizard doesn’t let you select discontiguous ranges of transactions to merge. This means I would have to start with the oldest transactions, select the contiguous range that ends with the first merge transaction, resolve all the conflicts and then check in the merged change set. Then I would have to do it over again selecting the next contiguous range that doesn’t include a merge transaction and so on. I have to check in in-between running the merge wizard because it doesn’t let you proceed if you have pending files in the target branch. Since a lot of the transactions in the $/Project-z branch represented work-in-progress that would mean the $/Project main branch would be essentially unusable until I had completed the entire process.
The second big problem (which follows on from the first) is that the versions of the files from the $/Project-z branch from the earlier transactions can differ significantly from the current versions. This means that there can be a lot of conflicts when older transactions are merged into the tip of the main branch. I looked at some of them and they can be mind-numbingly difficult to sort out. I would also have to do this conflict resolution over and over again with it (presumably) getting easier as the transactions get closer to the current version.
Any recommendations?
The second big problem (which follows on from the first) is that the versions of the files from the $/Project-z branch from the earlier transactions can differ significantly from the current versions. This means that there can be a lot of conflicts when older transactions are merged into the tip of the main branch. I looked at some of them and they can be mind-numbingly difficult to sort out. I would also have to do this conflict resolution over and over again with it (presumably) getting easier as the transactions get closer to the current version.
Any recommendations?