Frusterations with Vault

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
MarcusB
Posts: 24
Joined: Wed Oct 27, 2004 9:30 am

Frusterations with Vault

Post by MarcusB » Tue Nov 09, 2004 7:39 pm

What does this error mean?

File C:\documents and settings\marcusb\application data\sourcegear\vault_1\client\<guid here>\marcusb\_sgvault\<number here>\29163.0 could not be found?

I'm getting this error when I try and diff a file.

Also, does Vault have a problem when files are in the same logical folder on disk, but exist in separate projects in Vault?

Marcus

:?

sterwill
Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Post by sterwill » Wed Nov 10, 2004 1:57 pm

I'm currently working with a co-worker to solve your first problem (the error message). This can happen when a baseline file has been deleted from that folder but is needed for a Vault operation. But the name of the file is suspicious (it should not end with .0), and may mean the client is receiving incorrect information from the server for the diff.

How are you invoking the diff? Is it from the history explorer, or perhaps from the main window? Are you showing differences between two historical versions, one historical and one current, or one current and working folder version?

And for your second question, do you mean something like this?

$/folder is mapped to c:\working
$/otherFolder is also mapped to c:\working

This hasn't been heavily tested at SourceGear, but it should work without problems. A working folder stores its state data per file, and a file is identified by a number that is guaranteed to be unique on a given Vault server (across all repositories on that server).
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`

MarcusB
Posts: 24
Joined: Wed Oct 27, 2004 9:30 am

Post by MarcusB » Wed Nov 10, 2004 5:00 pm

I am invoking diff from the main window, as my file on disk is different. The status is unknown. I've also tries from the history window.

I wasn't able to check-in, either. I ended up copying my code aside, doing a get latest, and then copying my code over the latest version. Then I could check-in.

As for my second question, you answered it. I have a situation like this

$\project1 mapped to c:\project
$\project1\subproj1 mapped to c:\project

Vault didn't really like that, and each time I loaded VB, it would ask me if I wanted to add it to Vault. Even if I answer YES, it asks again the second time. Finally, I just changed my structure on disk to match Vault. Then it seemed to work ok.

sterwill
Posts: 256
Joined: Thu Nov 06, 2003 10:01 am
Location: SourceGear

Post by sterwill » Thu Nov 11, 2004 11:12 am

Vault does not allow you to check in a file with a status of Unknown, because it doesn't know which version of the file it was based on (its baseline version). Not knowing the baseline prevents it from being able to construct a delta to send to the server during the check in. A Get Latest Version (with "Modified Local File" set to "Overwrite") will put a known version into the working folder. Then you can merge your changes into this file and check it in.

Vault 3.0 has a feature to automatically recognize Unknown files if their CRC matches one in the server, so you won't have to manually tell Vault to overwrite these files. This is done during a Get Latest Version.

I hadn't considered IDE integration when thinking of sharing working folders. Visual Studio must have its own notions of the disk layout that conflicts with your arrangement.
Shaw Terwilliger
SourceGear LLC
`echo sterwill5sourcegear6com | tr 56 @.`

Locked