2nd Merge Branch (no change) still see differences, why?

Tri · Post by **Tri** » Wed Apr 18, 2007 5:31 pm

Server 3.16, Client 3.19

Scenario:
$/Project/Current/Code has 1 file (File1.cs)

A branch is created from The Current/Code folder to
$/Project/Release/Version_1.2/Code

1. After the branch is created, the file
Release/Version_1.2/Code/File1.cs is modified. The line // Change made after Version 1.2 branch was created is appended to the file.

2. Execute "Merge Branches", Origin folder = Release/Version_1.2/Code, target folder = Current/Code.

3. The Merge Branches wizard identifies correctly the history changes made in the branch since its creation. Select the changeset related to File1.cs and finish the remaining steps.

4. Current/Code/File1.cs is in Pending changeset with status Merged, after checkin, its content is indeed identical than Release/Version_1.2/Code/File1.cs.

5. Redo steps 2, 3, 4. Now the Current/Code/File1.cs file contains TWO lines "// Change made after Version 1.2 branch was created" (at the bottom of the file).

Q1. In Step1, if the change was inserted/deleted somewhere in the middle of file (instead of new content appended at the end of the file). Then merge wizard won't insert a duplicate change in Step5. Is it a bug?

Q2. What is the reason the Merge Branches wizard still sees a difference while the contents of the files are identical. This can be very confusing. For example, the team lead had done the merge. Let's imagine he is busy off site for a while. I give a hand to merge some changes back to the Current trunk. I can I know which changes the team lead had selected previously?

Q3. I would expect that the Merge Branches wizard won't display the changes which are already merged. Is it the case in Vault Server 3.5x?

Thanks in advance for any help.

Beth · Post by **Beth** » Thu Apr 19, 2007 8:17 am

I ran through your scenario and found it to be correct. Once I had more changes rather than just a line appended onto the end, it wasn't a problem anymore, and changes in the middle weren't reapplied either, but that one on the end looks like it could get applied twice until more changes are made that could be merged. Good catch. I'll log a bug.

Tri · Post by **Tri** » Thu Apr 19, 2007 8:20 am

Thanks for confirming. Any advice for Q2 and Q3?

Beth · Post by **Beth** » Thu Apr 19, 2007 8:26 am

On the other parts, merge branches doesn't remove the items from the list that you had already applied. It would attempt to merge the changes, but since that stuff would already be there if it was applied once already, it causes no problem. It's only with that line at the end that you found that it's adding it again, and it shouldn't.

Tri · Post by **Tri** » Thu Apr 19, 2007 9:08 am

So Am I right assuming that the Merge Branch wizard will list all changes from the present moment to the time where the branch was created?

Any merge previously applied in between are ignored (because they are still listed in the "Select Changes to be Merged" dialog.

The list of change could become pretty long, that makes the reading harder because most of them were already applied. And especially when the developer forgot to comment the changeset at check in time. It would be nice to have a checkbox "Only list changes which are not yet merged".

Is it doable?

Beth · Post by **Beth** » Thu Apr 19, 2007 10:26 am

Yes, it lists all changes. I can put in a feature request for tracking what's been merged. I'm not sure at this time the feasibility. The developers look at what's logged and have a meeting on each item to discuss them.

Tri · Post by **Tri** » Fri Apr 20, 2007 1:44 pm

Beth wrote:I ran through your scenario and found it to be correct. Once I had more changes rather than just a line appended onto the end, it wasn't a problem anymore, and changes in the middle weren't reapplied either, but that one on the end looks like it could get applied twice until more changes are made that could be merged. Good catch. I'll log a bug.

Is this fixed on the just released Vault Server 3.52? Does the new version has any of the improvement requested in the beginning of this post (not showing merges which were already applied).