Quick fix for UNKNOWN status

[jeremy_sg]

Don,

So the problem is that you don't want every file on your local machine? Try this: use the Search tab in the client to search for Unknown files. Then Select them, right click and choose Get Latest with no overwrite.

-Jeremy

[hensz]

Hi!
Just now I need the exactly this feature. I installed the software to a new machine and the location of the working and cache folder changed. Now all files have unknown status.

I have thousands of old files, and these files must stay in this status - so Get Latest Version is no option.

What is the status of the Feature 14141? Or is there a different workaround?

My current approach is: For each folder perform a folder diff, manually check the differences for each different file (so I must check only several thousand files, not several hundred thousands), the get all unknown files using a search for unknown.

Best regards,
hensz

[Beth]

I don't have any status update on that particular feature request.

None of the work-arounds mentioned will cause you to lose any of your code. If you performed a Get at the top level with the option "Do Not Overwrite/Merge Later," it will resolve the unknown status and will only get files that don't currently exist on disk. Jeremy's suggestion also will not cause you to lose any code changes.

[hensz]

The suggested workaround will not result in code loss, but in "not compiling anymore". I had a certain set of code files that compiled without an error. The latest version in Vault doesn't compile (at least not without many manual corrections), so this approach will "break" my code.

The approach I tried to use (only "get latest version" for those files that are "unknown" and not different) is also no good solution, since I clicked the wrong menu entry in some folders, leaving me with a totally weird state of code. The result was: Get latest version of all files (except those that I have changed manually), then build, track down all compiler and linker errors. This took me about 1 week, since building the entire code takes quite some time, and there were many errors, forcing me to fix them, then start over from the beginning...

[jeremy_sg]

Is this a common occurrence for you? I understand that our tool failed you in this case. If you want to avoid this pain in the future, use the option to store cache information in the working folder. With that option you can move the working folder and cache together. Warning: when you set that option, everything will go unknown again.

Another possible way to trigger the unknown file resolution is to open that folder in the GUI client. That usually resolves the unknown files. You would just need to click on every folder in the GUI client. Doesn't that sound like fun?

[GregM]

For several versions now, I have not been able to resolve unknown status in a folder with anything short of a get on the whole folder or a get or diff on each file. It used to be that a diff of one file in the folder would refresh the whole folder, but no longer, as described earlier in this thread. It's not something that happens a lot, but every once in a while I manage to corrupt a baseline file (entirely my fault), and have to delete the _sgvault folder and start over.

[Tonyb]

+1 for this feature.

I ran into a similar problem when I had to switch to a different computer. Compute A had the newest code (latest revision + changes). Computer B already had a working copy checked out but a very old revision.

Computer A's primary HDD drive failed so I had to start developing on Computer B. I just copied my working folder from A to B and now I have TONS of files that are in "Needs Merge" status when they could be in "Modified" status.

My guess is that I did something wrong (Maybe I should have "got latest" on Computer B before moving the files from computer A?) but Vault isn't helping me figure out what is going on after the fact. I have tried "Get Latest" with "Do Not overwrite" selected but all my files are still in "Needs merged" status.

I think the feature everyone here is looking for is "Update my baseline files to the newest version without doing anything at all to my working folder". I think doing a "Show Differences" with "the current version in the repository now" is doing just that.

[pmudditt]

+30 for this one. We really struggle to understand how this is not seen to be THE BIGGEST problem with vault & fortress. All we want is for a GET with NO OVERWRITE of ANYTHING so that we can get rid of the status "Unknown". The LAST thing we want to do is get the LATEST version but as most people know the get latest version with "do not overwrite" selected WILL overwrite OLD files which is not what you want to do sometimes especially when you have had to do a PC rebuild/move or have cleared the cache folders to try and get rid of the program mis-behaving problems.

[Beth]

I will add your vote on the unknown status feature request.
F: 14141

I don't think the option to Do Not Overwrite/Merge Later should overwrite old files, so I will be logging a bug on this for the developers.
F: 15540

A Show Differences at a file level will also resolve an unknown status. I ran a quick test on something that should end up with an Old status and it received the Old status.

Were the files that were Old modified as well? When I ran a test on what you reported, I found if the Old files were modified, they went to a Needs Merge status.

If the files were unmodified and Old, then as a last resort you can retrieve them from history again.

[pmudditt]

Just to further explain our working environment may help to understand why "old" files really need a bit of tender loving care.

For our embedded developments, we create a number of products that share a substantial amount of code with other products either as source code or as library modules.

Now an improvement in a shared piece of code on product "A" will be tested on product "A" that first requested it, however we do not want this "potential improvement/potential new bug" to be added to product "B" in an uncontrolled manner i.e. without testing that the new feature also works well in product "B".

Under these circumstances the product B developers spot the "old" status and recognise that a module must have been changed by another team.

They then choose to test the new version now or later by either getting the latest version or pinning this file back to the version that is in current use on product "B".

This example is where as far as product "B" developers are concerned the "old" tested version is preferable to the "latest" code tested on product "A".

I guess the reason that many people have not raised this as a really big problem is that even in our company people "assumed" that "Get with no overwrite" did that function. It does not !, it actually mean "I will not overwrite a file that I know nothing about because it has been modified but if I have seen it before because it is old I will overwrite your trusted old file and replace it with the latest potentially bug filled latest file for you !"

[Beth]

Something that might help your situation is placing a label at the version prior to the changes that would include the old files. Labels take up very little space, so feel free to use them heavily. Then, the users that need old files of a particular version could just perform a Get on the label.

[GregM]

I don't think the option to Do Not Overwrite/Merge Later should overwrite old files, so I will be logging a bug on this for the developers.
F: 15540

That option only applies to *modified* files. By definition, old files are not modified. Get Latest with this option would be a completely useless function if this option applied to old files.