Delete duplicate problems

[wes@encomia.com]

I currently have an automated QA build running every night to build our latest applications and check them into the vault for the QA team to get every morning.

There is no need to keep history for these builds and in order to save space in my SQL db backup files, I delete the last QA build before I add the new QA build. (hint, hint: add a feature that lets you *not* keep history for files)

The problem with doing this is that it seems there's a bug in the way the SG client keeps the cache of files. When my QA team tries to get the latest QA build, they have a duplicate entry of the zip file from the previous day in their source tree. The file is the same name each day. Trying to get either one of the file entries does not work. The invalid (deleted) entry fails with an "object does not exist" message, but the valid one does not fail or retrieve the file.

The only way to cure this is to have the user delete their cache. But it occurs the next day as well, and deleting the cache every day is not an option.

Am I doing something wrong? Is there a way to avoid this? If I don't delete these zips, my SQL backup file bloats to an unmanageable size.

version 2.0.6

Wes

[dan]

This sounds like a bug, but we'd need to reproduce it here to figure out what is going on. I just tried some simple actions (deleting and adding the same file multiple times), but so far no luck. Can you outline the exact steps you are taking? For instance:

1. Bring up GUI client
2. Add zip file
3. Delete zip file
4. Close client, etc.

Also, are you storing your baseline files in the client cache or in the working folders? (It shouldn't make a diff, but might help in reproducing it).

[wes@encomia.com]

first, several things:
- I'm using the CMD line interface to call vault.exe (vault.exe add -commit blah.zip, etc)
- the zip files (QA builds) are large: 20mb+
- the build system is on a different machine than the duplicates

CLIENT MACHINE
1. get zip file
2. close sourcegear GUI

BUILD MACHINE
1. delete tree from disk
2. get entire tree
3. edit zip file
4. delete repository version of zip file
5. add new zip file to repository

CLIENT MACHINE
3. see duplicate files

Now, the after trying to reproduce this by hand, I can't!!!! It only happens in my automation script. This script takes about 20 mins to run, so I've been trying to do this by hand.

I don't have any more time to devote to this today, I'll pick it up again tomorrow.

Once I'm able to reproduce this I'll post up.

Also, are you storing your baseline files in the client cache or in the working folders? (It shouldn't make a diff, but might help in reproducing it).

client cache (Document and Settings/User/App Data/Vault right?)

[dan]

More info on this: if you also obliterate the deleted item, it should trigger this bug. I've been informed that we have actually fixed this in the upcoming 3.1 release, so look for that when it comes out.