Merging long-running feature branches

[Ralkarin]

Here is the background for my problem:

We have a stable development trunk.
We created a feature branch to work on a seperate component.
During the lifetime of the branch, there have been many revisions to the trunk.
We are finished with the development of our feature and want to push the changes back to the trunk.
We periodically merged trunk changes into the feature branch (once per week, only moving the changes made that week), and we resolve conflicts and changes in our branch.

Ok, that's some background.

We want to push the feature back into the trunk in the most stable state possible, so in order to do that, we periodically merged changes made in the trunk to the branch and resolved the merges there. Effectively, the feature branch now contains all of the updated trunk code + the changes we made for the feature. So the only changes in the branch are the new and updated changes.

My problem when using Vault comes when I use the Merge Branches utility. I have to select a contiguous region of changes to commit back to the trunk. So I select every change made in my feature branch when merging from feature branch -> trunk. The major problem is, I don't just get the delta changes, EVERY file that was updated in the branch as a result of the merges from trunk->feature branch, shows up in the list of modified files. So what I end up having to do is manually look at 75% of the files being "not modified" or "the same ignoring white spaces" in my pending change set and the merge takes a lot longer than it should. Ideally, my pending change set should only have the files that have been updated in my feature branch, not including files that are the same in the trunk and in my feature branch as a result of the merge. But because I had to select the merge change in the contiguous region list, those files show up in the list.

Is there an easier way to manage this with Vault's merge tool? Perhaps a source control paradigm shift for our development style is necessary...

Thanks in advance,
Josh

[Ralkarin]

Here are some images and explanations for clarification:

The file referenced here was changed in the trunk. It got pushed into the feature branch during a trunk->feature branch merge. This file was NOT changed in any other way in the feature branch. Therefore, after the merge, the file is exactly the same in the trunk as it is in the feature branch.

This file does however show up in my list of changed files to select during the merge process. Afterwards, it shows up as a pending change in my pending change set.

The [Pending Checkin view of file] image shows that the file shows up in my pending change set as "Size Unchanged" and being "Modified".

The [Reference view of the merge] image, shows the reference view of the Fortress Diff/Merge tool (we use both tools here, for this example, I am only using Fortress' sgdm.exe as my diff/merge program from Vault). Note here that both the origin and the target are exactly the same.

The [Edit view of the merge] image, shows the result of the merge, which is identical to the origin and the target files, but it still shows up as a change in my pending change set.

This happens for nearly every file that was unmodified in my branch as a result of merging the trunk to the branch.

[jeffhostetler]

I'll have to defer the "how best to use Branching and Merge Branches"
questions to someone else, but I can talk about DiffMerge.

The reason that you're seeing the center panel with the single
large edited section is that DiffMerge sees the change as an
identical change in both the left and right sides relative to the
common ancestor. DiffMerge doesn't get any of the history,
just the 3 files, so it doesn't know anything about how the
changes got there. The auto-merge feature then applies
the change to the common ancestor giving the new merge result.
So the center panel in the edit view is 'dirty'.

As for your other question of seeing what has been changed between
the trunk and branch, you might try using DiffMerge's folder window.
Load up the trunk and branch root directories (so that relative paths
within each are the same). This will let you see what files are
different in the two sub-trees (and any new/deleted files). You can
double click on the rows in the listbox and see pair-wise diffs between
the current versions of the individual files.

You might use this along side the merge branches to help guide
you to the important stuff.

Hope this helps,
jeff

[GregM]

Jeff, would it help here if the merge wizard didn't check out files in CVS mode, and just modified them? This way the CRC could be used to detect that the files weren't modified, and eliminate them from the pending change set.

[Ralkarin]

Jeff, Thanks for the explanation of how DiffMerge works with branched files during a merge. I will have a look at DiffMerge's Folder window to compare the two folders when we work with large merges like this in addition to the merge tool.

I think Greg's question is what I was trying to get at. Would it be possible for the merge tool to remove them from my pending change set since they are effectively the same (using my configured RuleSet)?

If it makes a difference, we use CRCs as Greg mentioned on files smaller than 10MB. I'm not sure where this falls into the whole process.

[Beth]

On the first post here about the merges showing up and change sets, I could put in a feature request for a change there. In the meantime, lots of comments and labeling will help you identify which is a change from the feature branch, and which was code merged from the trunk.

Do you release from that branch? Is there a particular reason why you merge the trunk out to the branch?

[Ralkarin]

Thanks Beth,

We do not release from our feature_branches, we merely use them as a way to isolate long running feature development from our trunk. Because the feature branch has the potential to live a long time because of new development, we do not want to let it grow independently of the changes made to the trunk. So we push updates to the trunk out to the branch in order to resolve any conflicts in our branch, leaving the trunk stable. Waiting until the feature is complete could result in a catastrophic merge to the trunk.

Here is a link that describes what we are trying to accomplish with our feature branching: http://svnbook.red-bean.com/en/1.2/svn. ... nuses.html The section named "Feature Branches" describes the process we are following to keep our branches up to date. Note that we don't do this for every feature, just long running potentially breaking changes, or at times when we need stability in the trunk (an upcoming release -- starting development on a feature for the NEXT big release, not the one being developed).

I think the biggest problem is the merge tool checking out files that are the same between the trunk and the branch, forcing me to look at unmodified files in my pending change set. These files make up a large amount of the changes during the merge process if there were a lot of changes in the trunk pushed to the branch, whether the changes made to the trunk affected or touched any of the code modified in the branch.

[jeremy_sg]

Ralkarin and GregM,

I see what you're saying with the hassle of checking out files that result in an unchanged file. Usually when I merge branches, one of my first steps is to sort the pending change on the Details column, and show differences on all of the Size Unchanged ones (just to make sure that there weren't any changes) and undo those checkouts. I think that turning on the CRC checking in the options will also convert a lot of those to Checked Out Unmodified, which lets me bypass the show differences step.

We're taking a long look at merge branches to find the ways that we can improve the user experience, and you've pointed out a really good place for improvement. I think that it would be even better if the Merge Branches wizard would walk you through dealing with all of the Needs Merge files and Show differences, so that you aren't just dumped back to the main window thinking "Now what?".

[GregM]

Usually when I merge branches, one of my first steps is to sort the pending change on the Details column, and show differences on all of the Size Unchanged ones (just to make sure that there weren't any changes) and undo those checkouts.

That's what I do too. However, it's a real pain, and something that Vault should be doing for me.

I think that turning on the CRC checking in the options will also convert a lot of those to Checked Out Unmodified, which lets me bypass the show differences step.

That would be nice, but that's not what happens, as far as I've seen. The only way to tell if they're modified or not is to do a comparison.

[lbauer]

Thanks for the suggestions. We're planning improvements to Merge Branches in the future, and will take you comments into consideration.