Where is "Don't Get local copy" for checkouts?

[Lumberjack]

We just upgraded from VSS to SGV, and one (of many) features that I am yet to find matching functionality is the elegant & allways functional "Don't get local copy" checkbox on the checkout dialog box.

You know the one - it only checks it out on the server, but doesn't touch the local file that you've been working on. This is especialy handy for those file types that you don't use dev studio for.

Instead I am provided a combo box with the title "Modified Local File" & the ill named "Do not overwrite/Merge later".

At first glance this WOULD be the equivilant functionality - but you would be dead wrong if you just upgraded to SGV. You see, instead of "do not overwrite" - IT ACTUALLY OVERWRITES the local copy.

It would seem that instead of doing what documentation says, it does overwrite the local file. And several of my coworkers have had the same frustration.
The help file reads:
" This will not overwrite an existing file if it has been changed locally. Vault will still download a new repository version into the hidden state folder if one exists, allowing you to manually merge the file later"

Well, I don't know how to set the temporary directory, but the DiffMerge tool does. It shows a temporary directory in the path name of files to be compared.

All I ask is where do I find a WORKING "Don't get local copy" checkout in vault that will NOT MODIFY THE LOCAL COPY????

-Lumberjack

[dan]

The Do Not Overwrite option should work the way you want it to (it shouldn't overwrite files that have been modified locally). I just now ran a few simple tests to verify it in case we missed something obvious and it seems to work as I would expect.

A few questions:

1. What is the status of the file prior to the checkout (Old, Edited, Unknown, etc)?

2. If you can reliably reproduce this, can you list the exact steps, and the results of each step, so we can reproduce it here?

3. What version of Vault are you using?

[Lumberjack]

1. What is the status of the file prior to the checkout (Old, Edited, Unknown, etc)?
The status field was blank.

3. What version of Vault are you using?
From the about box -> SourceGear Vault Client - Version 2.0.2 (2163)

2. If you can reliably reproduce this, can you list the exact steps, and the results of each step, so we can reproduce it here?
1. We have been using VSS for years with DevStudio6
2. We imported the SourceSafeServer to SourceGear Vault.
3. Prior to opening my project in DevStudio, I purged my .OPT and .SCC files.
4. In DevStudio6, I opened a project that was previously in VSS - but is now in SGV.
5. I modified my source code.
6. I closed DevStudio
7. In the SGV Client I did a project compare to view the files that were different (and lamented the loss of context menu options to check in/out files from this view)
8. In the SGV client, I right clicked on the file that has the same name as my localy modified file & selected "Check Out"
9. From the "Modified Local File" combo box, I selected "Do not overwrite/Merge later" & clicked "OK"
10. To my horor, the file was changed!

[dan]

It sounds like the status of the file should have been Edited or Renegade if you had modified it, rather than a blank status (which means it is the same as the latest version on the server).

If you were to do these steps again, do you get the same results?

[lumberjack]

Yes, I can duplicate it with another project that was originally in VSS & then imported into SGV.

1. SGV Client, found an old project. It displays a status of "Unknown" for all the files. Local version is blank & remote version has numbers. The VSS history for these files also appear to be intact.
2. SGV, show differences on the project, "current version in the repository now", recursive
3. Acording to DiffMerge, all files are identical.
4. I modify one of the files in notepad & save it without the readonly flag
5. SGV, show differences on the project, "current version in the repository now", recursive
6. DiffMerge shows the changed file
7. SGV, I attempt to check out the file that I changed with the option "Do not overwrite/Merge later"
8. My file is now overridden.
9. Under further examination, there is a backup of my modified file in the "_sgbak" hidden sub directory with a timestamp like extension.

It still looks like a repeatable bug to me.

[dan]

Ah, I think this is mostly a misunderstanding of what "Unknown" status means. See http://support.sourcegear.com/viewtopic.php?t=162 for an explanation of Unknown files. Essentially, you can't checkin a file that is of Unknown status, so you'd have to overwrite it to get a baseline for checking it in later.

However, after playing around with this, I did reproduce what you are seeing. If the file status is Unknown AND you choose Do Not Overwrite in the checkout dialog AND the option to prompt before overwriting files is off, AND the global default is to either overwrite or to attempt auto merge, it ignores the setting in the Checkout dialog. I believe it won't overwrite if any of these conditions aren't true. Also, as you figured out, we also backup files that are overwritten by default.

While this shouldn't happen, the larger issue is that we probably should simply not allow users to checkout files with an Unknown state, since they can't be checked in until they are overwritten.

[Guest]

While this shouldn't happen, the larger issue is that we probably should simply not allow users to checkout files with an Unknown state, since they can't be checked in until they are overwritten.

I think you're a little backwards in your logic - or it's a fundamental design flaw in the product.
Why does a file need to be overwritten in the first place?
Can't the client (attempt to) read the local file during the checkout & go "wow - that file allready exists it must be a renegade or something"?

All I'm asking is that you have a WORKING option to check out without actually modifying the local file. It's something that VSS has mastered quite well.

[dan]

While I would not normally discourage anyone from calling my logic generally backward , I think a better understanding of Vault's baseline files and Unknown file status would help. Note that your frustration with not overwriting files on checkout only happens to files with status Unknown, which is not a normal or regular file status in Vault.

Unlike VSS, Vault sends only the changes you make to a file to the server (greatly increasing performance), and it only stores those changes on the server. In order to know what changes you made, it needs to know what file version (the version of the file in the Vault server) you started with. If it doesn't know what version you started with (because you've never done a Get from Vault), its status is Unknown, and Vault can't do much with the file, since it can't compute the delta.

In your case, there is no baseline file, because you never did a Get from Vault. Vault could assume your baseline is the latest version (which is what I think VSS does), and if we did, we would be overwriting other people's changes on the server if your baseline isn't the most recent version, making people think that the Vault server is stomping on their changes, which is far worse than overwriting a Unknown file on the client (and backing it up in the backup folder).

Vault does need to do a better job of identifying Unknown files with versions that are actually on the server. However, once you've modified the file, it doesn't match any version on the server, and there is no way to compute the delta.

I think the missing step here is that you need to do a Get Latest from Vault to put files on the local machine and not just edit files that were there before, or copy them from a different source. Just because files of the same name exist in a working folder doesn't mean Vault knows which version they correspond to, even if you do. Vault has to do the Get Latest to establish the baseline. After that, choosing to not overwrite files on checkout works exactly the way you want it to.

[lumberjack]

If it doesn't know what version you started with (because you've never done a Get from Vault), its status is Unknown, and Vault can't do much with the file, since it can't compute the delta.

Maybe I'm just not "getting it", the file that is in the vault server was originally imported from VSS (and contains all of VSS's history) - so it does have a baseline of sorts.

Vault does need to do a better job of identifying Unknown files with versions that are actually on the server. However, once you've modified the file, it doesn't match any version on the server, and there is no way to compute the delta.

First part I agree with, however why would it be so hard to figgure out the delta? Just have the server send an MD5 hash of it's historical "versions" & have the client generate it's own local MD5 hash & compare them. If one matches - well you've got a match. If one doesn't, put on your thinking cap & send multiple hashes of the latest version that represent a percentage of the file - or send the whole file itself to a temp dir & compare it in detail.

I just don't understand why marking a file as checked out would require the modification of a local file. In my mind when you check out a file you are telling the other developers on your team - "don't muck with it, I'm working on something". How is it different in SGV? Why is it so much more than a flag?

[dan]

Maybe I'm just not "getting it", the file that is in the vault server was originally imported from VSS (and contains all of VSS's history) - so it does have a baseline of sorts.

A baseline must be a version that exists in Vault. If you modify the file before the baseline is established, there is no longer a way to determine which version you started with. Remember that this is only a problem with files of status Unknown. Files of any other status work fine.

First part I agree with, however why would it be so hard to figgure out the delta? Just have the server send an MD5 hash of it's historical "versions" & have the client generate it's own local MD5 hash & compare them. If one matches - well you've got a match. If one doesn't, put on your thinking cap & send multiple hashes of the latest version that represent a percentage of the file - or send the whole file itself to a temp dir & compare it in detail.

Comparing a hash is exactly what we plan to do to resolve unknown files against known versions in Vault. However, if your local file doesn't match a Vault file, there isn't a way to reliably establish which version it started at.

I just don't understand why marking a file as checked out would require the modification of a local file. In my mind when you check out a file you are telling the other developers on your team - "don't muck with it, I'm working on something". How is it different in SGV? Why is it so much more than a flag?

Checking out a file in Vault is exactly a flag that indicates you intend to check it in, and if you check it out exclusively, no one else can check the file out until you unlock it.

The problem isn't with the checkout, but with the checkin. In order to checkin a file it needs to know the baseline to compute the differences. A Get needs to be done on the file to establish the baseline (and a Get is part of the Checkout). After that, all other checkouts and checkins should proceed normally, and you shouldn't see this behavior.

Again, this is only a problem with files that have Unknown status, which isn't very common, since it generally only happens when you are switching from a different SCC tool or switching working folders to a folder where files of the same name already exist.