Serious issues with "Get Latest Version"

Scootin159 · Post by **Scootin159** » Wed Apr 12, 2006 7:43 am

We noticed the following scenerio yesterday:

Person 1: I added a form to our VS 2005 project
Person 1: Modified the form
Person 1: Checked In form

Person 2: Did a "Get Latest Version", got form v1

Person 1: Checked Out form
Person 1: Deleted the form using VS 2005
Person 1: Re-added a new form under the same name
Person 1: Checked In form (v2)

Person 2: Did a "Get Latest Version" of solution recursively
Person 2: Still saw form v1
Person 2: Got compile error, got latest of form specifically
Person 2: Still saw form v1
Person 2: Checked out form to fix compile error
Person 2: Undid checkout
Person 2: Now, finally saw form v2

This is a SERIOUS bug in our book, and basically means sourcegear is USELESS to us, and we will have to switch back to sourcesafe. What is the point of source control software if you can't trust it to perform a basic "Get latest version" correctly? This means we could have builds which don't contain the bug fixes we think they do, which is completely unacceptable.

I did find this link through google: http://support.sourcegear.com/viewtopic.php?t=5750

Is this the same issue, and if so, why on earth would such a major bug not be considered a 'life and death working on it 24/7 should have bug fix in a few hours' level bug. A delay of a few months on this bug fix would mean we can't do any releases for a few months.

I will admit we are using version 3.1.7 (client & server), but I don't see this as being fixed in version 3.1.8, and don't intend to go through the upgrade process in blind hope.

dan · Post by **dan** » Wed Apr 12, 2006 9:33 am

Some things to note about this bug:

1. It only happens on the first Get Latest after someone has deleted and re-added a file of the same name and your Repository Deletions option is set to "Remove working copy", and you didn't do a Get latest between the time the other user deleted the file and re-added the file. The second Get refetches the files correctly.

2. It has an easy workaround: set the Repository Deletions option to "Do Not Remove Local Copy"

There's no question this bug is disconcerting, and I don't mean to minimize it, but it should not affect your builds if you apply the workaround. If you don't want to change that option, your build should work again if you merely rerun it (since a 2nd Get will clear out the problem).

We have been looking at it since it was reported a few weeks ago, and we should have a fix available soon.

Scootin159 · Post by **Scootin159** » Wed Apr 12, 2006 10:37 am

dan wrote:It only happens on the first Get Latest after someone has deleted and re-added a file of the same name and your Repository Deletions option is set to "Remove working copy"

I'm assuming you're talking about the PC which is applying the changes? If so, in the example above, I had mine set to "Remove working copy only if unmodified".

dan · Post by **dan** » Wed Apr 12, 2006 10:47 am

The user that is doing the Get needs to have his/her Repository Deletions set to "Do not remove" (not the user who does the delete/re-add). Both "Remove working copy" and "Remove working copy only if unmodified" will trigger it.

Scootin159 · Post by **Scootin159** » Wed Apr 12, 2006 11:07 am

We just tried the following sequence:

PC2: Got latest of file

PC1: Set to "Do not remove local copy"
PC1: Deleted a file in VS2005 & chose "Delete from repository"
PC1: Re-added a file under the same name
PC1: Checked in file via VS2005

PC2: Got latest of solution, still have V1
PC2: Got latest of file in quesiton, still has V1
PC2: Set to "Do not remove local copy"
PC2: Got latest of solution, still have V1
PC2: Got latest of file in question, still has V1
PC2: Checked out file, Still has V1
PC2: Undid checkout, Now has V2

Is there something else to the workaround? From this experience it seems as though the workaround isn't working.

dan · Post by **dan** » Wed Apr 12, 2006 1:45 pm

By version 1, do you mean it reports it as being version 1, or that the contents are still the old file? Note that if you delete a file and re-add it, it becomes version 1 on the server, as all the previous versions are deleted along with the file.

Scootin159 · Post by **Scootin159** » Wed Apr 12, 2006 2:16 pm

dan wrote:By version 1, do you mean it reports it as being version 1, or that the contents are still the old file? Note that if you delete a file and re-add it, it becomes version 1 on the server, as all the previous versions are deleted along with the file.

I'm refering to the data in the file. I haven't actually checked what version # source gear refers to it by.

dan · Post by **dan** » Wed Apr 12, 2006 3:07 pm

OK, I see what is happening.

The problem is that when you delete a file and re-add another one of the same name, the new file is a completely new entity in Vault - it is no longer tied to the working file in your working folder.

So, when the client does a Get Latest, and there is a file of the same name already in that folder, its status is Unknown, because Vault doesn't know what version it is. It tries to match contents against a known version in the repository, but since you've deleted the old versions in Vault, it can't find a matching version. So, the file becomes Edited or Renegade, because the local file it has is different from the one that is checked in, and doesn't correspond to any known version.

When you do a Get, it doesn't automatically overwrite a file that is determined to be "Edited", so it doesn't overwrite the file, it leaves it as an edited file.

You can easily correct this by choosing "Overwrite" in the Get, but you probably don't want this to be the default setting for Get.

The higher level issue is that deleting and adding a file of the same name is conceptually very different from checking in a new version of the file, so you'll need to handle it specially when that happens, by doing a Get with Overwrite.

Since files on your build system are presumably not edited by the build server, you can safely choose the Overwrite option there though, and your builds should continue to work.

Scootin159 · Post by **Scootin159** » Thu Apr 13, 2006 7:34 am

Dan, your response makes sense to me. It sounds as though in order to get the expected behavior we need to set our options to "Overwrite" on all our machines (using the prompt option).

We've set our machines to this setting, and it works as expected with a "Get Latest Version", but not when we do a "Check out". It looks as though we'll need to do a 'get latest version' before a check out. Is there a setting we can use to have this carry through on a check out?

dan · Post by **dan** » Thu Apr 13, 2006 9:17 am

I'm not able to reproduce this in a simple case, but maybe I am misunderstanding: If I checkout a file in an Edited or Renegade state, and have my options set to Overwrite and Prompt, it will prompt me before overwriting the file.

However, note that the prompt is only displayed if a modified file really is about to be overwritten. If the status of the file is blank or old, then the prompt would not be displayed, because the file hasn't been modified locally.