Deleting a file then replacing it can lose the replacement

Dragon2000 · Post by **Dragon2000** » Tue Apr 17, 2007 9:26 am

We've encountered a problem!

Say two (or more users) are working on the same project. They both have up to date copies of the project containing identical versions of a form: Form_A.
Now person 1 comes along and deletes Form_A and replaces it with a completely different form that is still called Form_A.
If person 2 comes along and checks out the form it does not notice the change and person 2 continues to work on the original Form_A wiping out the new changes.

We're experiencing this in Access which I know you do not support but we can reproduce the issue in VB6.

Manually choosing Get Latest Version within VB works correctly but we're used to SCC doing that for us on check outs! Manually choosing Get Latest from Access causes an 'automatic merge failure' message.

Beth · Post by **Beth** » Tue Apr 17, 2007 9:38 am

Which version of Vault are you using?

I'm going to assume VB6 when going through this. Is the form then deleted from VB6 or from within the Vault GUI?

Dragon2000 · Post by **Dragon2000** » Wed Apr 18, 2007 3:06 am

Vault client and server are both 3.5.1.4786

What we are doing is right clicking a form in VB and choosing remove and saying yes to the option to remove from SCC. Then we exit VB and remove the .frm file from the hard disk. If you then login to VB and rename the filename of an existing form using File, Save As to replace the old one then the issue described above occurs.

I appreciate this isn't something you would do all that often in VB as the filename is independant of the form name but nonetheless it is somehting you are able to do if you want. Perhaps if someone was working on a form at home and brought it in as a replacement the next day?
In Access it's different as the file name is dependant on the form name and hence we are more likely to encounter this than most of your users I daresay.

I'm gonna suggest a possibility here but I have no idea how you check for changes so this is a complete guess that could be way off! Say everybody had version 15 of form_A and someone deleted it and readded it. Would form_A then be version 1? And if so would the clients deduce it was not a newer version than their v15? Having suggested this we did try the check using CRC option and that did not help.

mlippert · Post by **mlippert** » Wed Apr 18, 2007 2:19 pm

I've seen Vault have this problem.

What I think is happening is that the file in vault is version 1. This file is deleted, and then a new file w/ the same name is added. The new file is still version 1.

If someone had the old version 1 in their working copy, Vault doesn't recognize that it has changed, because there is still a file with that name and the same version number. At least this is what seems to be the issue at the base of this class of problems I've encountered. (And this is with Vault 3.5 and interacting with it using the Vault client, not VS)

Mike

Post by **jclausius** » Wed Apr 18, 2007 3:41 pm

Since the file's dates and probably contents would be different the file's status would be Renegade. A GET with the overwrite option would be required to overwrite the local file.

mlippert · Post by **mlippert** » Wed Apr 18, 2007 3:46 pm

Now that you mention it, I think you're correct that the file does become renegade. However that "feels" odd because I (the user) never changed the file, I only did gets from Vault. If I had managed to do a get after that file was deleted from Vault and before it was re-added, the file would not have become Renegade.

I expect Vault to catch this, although it's obviously not a straight-forward problem or it already would.

Mike

Post by **jclausius** » Wed Apr 18, 2007 9:07 pm

I'm not sure there is a real fix here. The Vault client can tell that a new file exists because the file has a different ID, but unfortunately the file system doesn't have this info. So the best thing the client can do is say there is something different about the file.

Dragon2000 · Post by **Dragon2000** » Thu Apr 19, 2007 2:35 am

It doesn't show as renegade for me, it shows as 'Needs Merge'

If I check out in sourcegear and view the file then it is correct.

However if I do my checkout in VB it shows me the old form. If I then go to sourcegear and view it in notepad it shows the new forms source with a status of merged. So it seems sourcegear is getting the file but VB is not being made aware that it's changed and is just allowing me to edit the file as it existed when VB was loaded.
Our users then go about changing the form blissfully unaware that they are undoing another users work. The phrase 'i'm sure i've already done that' has become quite a commonly used saying around our office of late!! I believe them now

mlippert · Post by **mlippert** » Thu Apr 19, 2007 8:03 am

Jeff,
I was just thinking about this. The file that no longer matches should still be the same as the one that Vault thinks is on the disk (ie it is identical to the hidden copy of your working version). That should be enough to trigger a check for a delete and re-add when it doesn't match the file on the server, before flagging it as renegade, which goes unnoticed for a while as the general safe practice is to do automatic merges w/o overwriting.

Of course this no longer sounds like Dragon's problem.

Mike

Post by **jclausius** » Thu Apr 19, 2007 8:13 am

Dragon2000 wrote:It doesn't show as renegade for me, it shows as 'Needs Merge'

If the file is in "Needs Merge" status, Vault will not allow the change to commit unless the file is merged from the server or the user clears the Needs Merge status.

Users should be wary of a needs merge status that cannot be resolved with a GET w/ automatic merge, and be cautious resolving merge issues.

Post by **jclausius** » Thu Apr 19, 2007 8:14 am

mlippert wrote:Jeff,
I was just thinking about this. The file that no longer matches should still be the same as the one that Vault thinks is on the disk (ie it is identical to the hidden copy of your working version). That should be enough to trigger a check for a delete and re-add when it doesn't match the file on the server, before flagging it as renegade, which goes unnoticed for a while as the general safe practice is to do automatic merges w/o overwriting.

Of course this no longer sounds like Dragon's problem.

Mike

I haven't tried this, but what happens if the "Perform local deletions" option is enabled during this scenario?

mlippert · Post by **mlippert** » Thu Apr 19, 2007 9:33 am

I have the "Perform repository deletions locally" option set to "Remove working copy only if unmodified".
And you're correct, an unmentioned assumption I made was that this was not set to "Do not remove working copy"

However, the answer to your question is that I do have it set, and it still made the file renegade rather than updating it. (Note that I am not trying this again right now, this is from memory of what happened in the past)

Dragon2000 · Post by **Dragon2000** » Thu Apr 19, 2007 10:02 am

jclausius wrote:
Dragon2000 wrote:It doesn't show as renegade for me, it shows as 'Needs Merge'
If the file is in "Needs Merge" status, Vault will not allow the change to commit unless the file is merged from the server or the user clears the Needs Merge status.

Users should be wary of a needs merge status that cannot be resolved with a GET w/ automatic merge, and be cautious resolving merge issues.

The problem is they aren't made aware of this within the scc addin within the IDE. Vault shows it but the IDE does not seem aware. Is there anyway for the scc addin to warn about this?