Merge issue - or am I missing something?

[BenM]

Hi all,

I seem to be running into an interesting problem with a largish merge I'm doing. After about 8 months of concurrent development, my project branch is to have the trunk (finally!) merged with it so it can be brought in line with our main product line and tested before being merged back into the trunk for release. I ran the merge branches wizard and all is well, 1000+ source files are happily checked out, many saying Needs Merge.

No problem says I, and I've gone through and manually reviewed the merge on each and every file. So far so good: It all makes sense.

Now I want to compile my target directory before checking in the merge. The problem is, some of these merge results are not showing up in the target file. Perhaps I'm a newb and doing something wrong, but I'm not so sure...

Consider this example. I have a file named DocOptions.h. One of its changes includes adding a new variable "FScanDuplex". I've right clicked on the file in the changeset listing, clicked Show Merge, ensured that FScanDuplex is added to the merge result, saved, exited, and responded Yes to "Would you like to resolve the merge status now?".



Now, when I click the "Show Merge" option on the context menu for DocOptions, it shows the Target File, Origin File and Merge Result to all include FScanDuplex:



I would expect this behaviour if the merge program had saved my changes in the target folder - the target file would now equal the origin file in this case.

However, if I open the local copy of the target file, its content is missing the new variable:



while the origin file definitely includes it:



It seems that in files where the Target has been merged correctly, the "Show Merge" option no longer appears on the context menu. These Target files include the new, merged content.

In files where "Show Merge" still appears (and won't disappear after showing the merge and saving the changes) the changes have not yet been written to the Target file.

So - am I doing something wrong? Is this a glitch? I realise I've not yet upgraded from 4.06 but I don't see anything related to this in the changes and don't want to upgrade until after the merge is safely completed.

Any assistance at all would be greatly appreciated.

Obligatory Version Info

- vault techsupport info

Client Information
Vault Client Version: 4.0.6.15954
.Net Framework Version: 2.0.50727.1433
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Total Physical Memory: 3.24 GB
Time Zone: (GMT+08:00) Perth

Server Information
Vault Server Version: 4.0.6.15954
.Net Framework Version: 2.0.50727.1433
Operating System: Microsoft Windows XP Professional
Service Pack: 2.0
OS Version: 5.1.2600
Timezone: (GMT+08:00) Perth
SQL Version: Microsoft SQL Server 2005 - 9.00.3068.00 (Intel X86)
Feb 26 2008 18:15:01
Copyright (c) 1988-2005 Microsoft Corporation
Express Edition on Windows NT 5.1 (Build 2600: Service Pack 2)

License Information
0 serial number(s):

- sgvault.log - nothing interesting has been added since well before the merge, ie

----8/18/2008 11:23:36 AM admin--localhost(127.0.0.1)--SSL Disabled Login
----8/19/2008 1:03:29 PM admin--localhost(127.0.0.1)--SSL Disabled Logout
----8/19/2008 2:36:26 PM admin--localhost(127.0.0.1)--SSL Disabled Login
----8/21/2008 1:22:26 PM admin--localhost(127.0.0.1)--SSL Disabled Logout
----8/21/2008 1:22:37 PM admin--localhost(127.0.0.1)--SSL Disabled Login

[BenM]

As a further thought, related to this thread:

In a few cases my workflow doing this merge was to:
1) right click on the file in the pending changeset, and choose Show Merge. Put diffmerge in the left monitor.
2) right click on the Origin file in the Origin folder, choose History, and diff the current version against an earlier change. Open this diffmerge in the right monitor.

Using the right monitor's diff I can see what the trunk coder has intended with their changes, while the left monitors merge allows me to pick and choose (and edit) the resulting merged file.

Is it possible, based on the above thread, that getting Vault to do anything (such as opening the history/diff) has broken the merge process?

If there was a GET with overwrite, the default Vault option is to save ALL edited work in the _sgbak folder. Assuming you have not changed that setting, any files you were working on would have been moved to the _sgbak on any kind of GET from the Vault server.

[Beth]

I tried the same thing on a recent version of Vault, and it gives a warning in the Diff window that says the file was changed and offers to reload it so that the Diff and the Merge match. I couldn't make it mess up the merge, but I might be missing a step. Could you provide an exact list of steps to reproduce (to the level of making them idiot-proof for me )?

[BenM]

Thanks Beth. The Diff was done on the Origin folder though, so since the merge is being done at the Target, you'd not see any prompt to refresh due to changes.

I just tried to make a sample project with a single source file, branched it, and then tried to do the manual merge. It behaved fine. Likewise I have done these merges with small projects in the past with no issue at all. I don't understand why it's misbehaving on my big project nor can I see any obvious difference between it and earlier, successful merges.

The only things that seem different with this merge is that the changes in the merge window do not appear in the target file and I am noticing a lot of "Add File" operations in the pending change set that I don't remember seeing before, like

which is also very interesting.

Either way, time is ticking and I have a lot of files to manually merge now so I'll have to come back to this later if I am to find a way to reproduce the problem for you. In the meantime if you can think of anything else that may cause this, and even better, a neat solution, it would be much appreciated.

Cheers.

[BenM]

As a further observation or two related to this issue, I notice:
1) that the sgmbhidden 'add file' operations listed in the last post are where new files were added to the trunk and need to be checked in to the branch when the merge is completed.

2) that there are a number of tmp*.tmp files in the c:\documents and settings\user\local settings\temp folder, which contain the merge results, like "tmp2532.tmp" which contains the merged DocOptions.cpp file that was missing in my original post.

If I can match the tmp*.tmp files with my original source files, I can manually sort out the original problem above. However, the way in which the new files are being added may also be a sign of future fun times. Since the new file doesn't also appear in the branches repository yet (it only appears as one of those sgmbhidden records, however the resulting file has been also copied to the branch's folder on disk), should I need to make changes to one of those newly added files, I may have even more exciting days ahead.

[Beth]

If I'm reading this correctly, the base issue is:

The problem is, some of these merge results are not showing up in the target file. Perhaps I'm a newb and doing something wrong, but I'm not so sure...

I didn't understand at first that by target file that you mean what's in the working folder. Did you save after merging? I thought I did the same thing in a test and came up with the correct results. Having Diff open at the same time didn't make a difference.

It might be easier if we took this offline. Can you send an email to support at sourcegear.com with a link to this thread?

[BenM]

No probs.

(ps... By saying "Origin" and "Target" I was only using the same terminology found in the Merge Branches wizard to try and make things clear... I failed! )

[Beth]

This issue is currently being worked on offline.

213247