Weird behavior

[mikebelotti]

Lately I've been noticing that my Vault has been acting up. I've noticed a few symptoms but I can't seem to form a pattern between them:

Changes are not automatically detected. I have the "Edit/Merge/Commit" style selected in the options menu, but Vault doesn't automatically notice changes I make.

Change set is not cleared after a commit. If I modify files and then commit, those entries remain in the change set even though they appear to have registered with the server. (However, other operations, like add/delete, are removed from the list.) I have to switch repositories to clear out my change set list.

After I add a file, its status is always "Unknown". I have to do a "get latest" on files that I just added so that the "unknown" status goes away.

It wasn't always like this; I'm trying to figure out what I could have done to cause it. I'm using version 5.0.3.18802. Any help is appreciated!

[Beth]

If you refresh, do files show up as edited or the committed files clear out of the pending changes window?

After you make an edit, are you saving the file?

How large are the commits you generally make?

Do you perform your actions in Visual Studio or in the Vault GUI client? Are you using both at the same time?

On the add file being Unknown, that seems like expected behavior. Files can be added from any location outside of the working folder, so we don't make the assumption that the file is in the working folder.

[mikebelotti]

Thanks for the reply, Beth. Refreshing doesn't clear out the pending change list; they sill remain "edited". I am saving the files after I edit them (but before I commit them), and the commits are usually less than a meg (mostly source code). I only use the Vault GUI client (not the Visual Studio one).

In the past, I've added files without them becoming "unknown"; only recently did this start happening. While it's kind of annoying, that's not as much of a problem for me.

[GregM]

Do you have this option enabled: Tools>Options>Check In>Always keep files Checked Out

[mikebelotti]

No, I don't have the "always keep files checked out" option on.

Another thing I noticed though: sometimes a commit fails because I "must merge my working copy with the newest version" on the server--even when I already have it. I can usually remedy this by moving my local copy of the file elsewhere, get latest, then copy my version back in and commit. It's just kind of time-consuming that way...

[Beth]

Can you post a screenshot of the setting you have for Concurrent Development Style?

That setting is in Tools - Options - Local Files, do you have the option to use CRCs checked? You might try using that to see if it helps.

Are you sharing a working folder with any other users?

[mikebelotti]

I checked the CRC option but I don't think it did anything different; I committed a change just now and it stayed in my change list. That's when I go, "hm, what's it still doing there?" I checked the message log and confirmed that the change went to the server, but it's still in the pending change list. If I try to commit it again, I get that "must merge your working copy with the newest version" message.

I am sharing a working folder with other users... It's necessary in my case. But it's never been a problem before. You're thinking that has something to do with it?

Thanks for the input so far. I attached my Concurrent Development Style below.

[Beth]

Sharing working folders causes all sorts of nasty things. Your items staying in your pending changes area when checking in does still seem strange even for sharing working folders, but to troubleshoot it, having your own working folder would help narrow this down and show definitely if it's the sharing of working folders causing it.

The things you are seeing happen with all your projects, right?

What you might try is create a test folder and add a dummy text file. Set that folder to have it's own separate working folder that no one else will touch. Then try making changes and checking them in. Does that work like it should?

[mikebelotti]

What you suggested with the dummy text file and different working directory seemed to work. I made a change and it committed and got removed from my pending change list.

But I don't think I understand 100% what you meant by sharing working folders... I'm not sharing my local computer; I'm the only one who uses that. However, many of the projects I work on are in a certain directory (say, drive:/dir/subdir), and that directory structure is mimicked on many others' machines. Basically, you could go onto any of our machines here and see a drive:/dir/subdir folder with our work in it. That's what I thought you meant by sharing a working directory, but now I'm not so sure.

If you meant using the Source > Share... function, then no, no one here uses that. Thanks though.

[Beth]

What I meant by sharing a working folder is setting a working folder to point to some central location, like a server, and then having all users point to that same location. and work from that disk location. If you only work on your own machine and no other users connect to your machine to work on files, then you are not sharing working folders. Mimicking the folder structure on multiple machines is allowed, but users are still each only using their own machine.

Since a new file is shown to work fine, and that you've mentioned that there isn't sharing of working folders, then I'll go in a little different direction.

Do all users have the same problems, or is it limited to just your machine? If it's just your machine, then I think we should make sure that your cache information is not the problem. Go to this KB article, http://support.sourcegear.com/viewtopic ... 13&t=11513. I'm going to have you rename your client-side cache instead of deleting it. Use the KB article instructions, but just rename the cache. Make sure all instances of Vault on your machine are closed before renaming the cache. Then see if that helps.

If you have pending adds, deletes, renames, or moves, you may want to commit those first, or make a note of which files you are making those types of changes to. Renaming the cache will cause those adds, deletes, renames, and moves to disappear.

[mikebelotti]

OK... Here's something I probably should have mentioned earlier I just didn't think it was the problem, but...

I wrote a small program that uses the Vault command line to automatically set the working folders of most of our repositories (client-side). It uses the "SETWORKINGFOLDER" command and runs through a list of repositories, setting each of their working folders. This way, when someone clears their cache, they can just run this program and have all of their working folders back.

However, since running that program, the working folder change appears to have took, but all of this weird behavior starts. If I clear the cache and then set the working folder manually, everything is fine. So I'm thinking it's something to do with the way I'm using the command line call. All I'm doing is:

SETWORKINGFOLDER -host ourhost -user someuser -password somepassword -repository somerepository $ drive:/dir/subdir -forcesubfolderstoinherit

...which is intended to set the repository root to drive:/dir/subdir. The command line client returns "True" for the success result, so I feel like I'm doing this right. Do you think the problem is anywhere in here?

[Beth]

I ran a quick test and still don't get the same behavior. What operating system are you on? It could be a case of where it is having problems writing to the cache to update it.

Do you have anti-virus? If so, try either turning it off temporarily to try a test to see if you get different behavior, or put in an exception for your Vault cache (%username%\local settings\application data\sourcegear).

[mikebelotti]

I'm running Windows XP. I have McAfee and Symantec for anti-virus. I tried disabling Symantec (I can't turn off McAfee) and I still get most of the same problems... Although, when I turned Symantec off, Vault was able to auto-merge a file that it couldn't before. I don't know if that was a coincidence or not.

I'm thinking that commands sent from the Vault command-line client when it's called up by a C++ application (which is what I wrote) could be seen as malicious and would be blocked by anti-virus. However, we did write another in-house app that uses the Vault command-line client just fine (it didn't use the SETWORKINGFOLDER command, but it did do checkouts and commits).

So if disabling anti-virus is what it comes down to...I could just abandon the app I wrote; it's not the end of the world. However, any other suggestions are certainly welcome.

[Beth]

Rather than abandoning your app, I think it would make more sense to set your working folder manually rather than the command line. It looked like you were just setting it at $, correct? That same action is easy to perform in the GUI client.

If you have to do that often, then we should instead be discussing why you have to keep clearing your cache.

[mikebelotti]

The thing is, we have over twenty repositories that use the same drive:/dir/subdir working folder for their roots. To do that manually is kind of a pain, which is why we tried to automate it.

We clear the cache pretty often because it tends to balloon up to (and over) 40GB if we don't keep an eye on it. Although I use Vault mainly for code, our company as a whole also uses it for media (like image files and video/audio), and we all use Vault pretty heavily. This may not be able to be helped, but I guess if there's a way to make the cache not get so big, that would be nice.

Anyway, thanks for your input, Beth.