All Checked in Files need merge, then go renegade after try

[bboland]

All Checked in Files end up reading "need merge", through the Vault client when I then attempt to "Get Latest" on that file it changes from "Need Merge" to "Renegade". Any ideas on what I would need to change to get this functioning as it is supposed to?

My Vault version is 4.1.3 and I am using VS2005 for development.

Thanks,
Brent

[Beth]

Are you checking in through VS 2005 or through the Vault client? If it's through VS 2005, then are you using the Enhanced or Classic Client?

Are you seeing the Renegade in the Vault GUI client? If so, does it remain Renegade if you refresh the client or close and reopen it?

[bboland]

Thanks for the response.

We are checking in through VS2005 using the Enhanced Client.

I am viewing the status of the file using the Vault Client on the server where the application resides.

The file remains Renegade even after a refresh or closing and re-opening the Client.

Thanks,
Brent

[Beth]

Is the Visual Studio instance that you are using for making the change also on the server or on your local machine?

Do you have multiple clients all using the same working folder?

[bboland]

Thanks again for getting back to me on this. The Visual Studion instance in on a different machine, it is on my local machine.

There are 2 of us that use Vault on 2 separate local machines that each use the same working folder for the application on the server but are working from copies on each of our respective local machines.

I hope that helps.

Thanks,
Brent

[Beth]

If the issue is occurring on the server where both are pointing to the same working folder, then what you are seeing is a normal result of multiple people using the same working folder. Every user has their own cache. The cache is used for determining the file status.

Since I'm unsure yet if this is the case for you, I'll describe in general what happens here. Let's say 2 users are both using the same working folder. That means 2 caches are trying to determine status on the same working folder.
1) User 1 checks out the file, so that user's cache knows there is a check out.
2) User 2's cache does not know about the check out, because User 2 has not checked out the file.
3) User 1 edits the file and receives an Edited status.
4) User 2's cache will notice that the file changed, but since there wasn't a check out, it receives a Renegade status.
5) User 1 checks in and has no status.
6) User 2's cache cannot capture the check outs and check ins of other users, so all it knows is that it has a changed file on disk that was changed without User 2 checking out. Status remains renegade.

User 2 could resolve the Renegade status by performing a Get with Overwrite, but there is a very large potential problem with that. User 2 will see the renegade status as soon as User 1 starts editing the file. If User 2 performs a Get with overwrite before User 1 checks in their changes, then User 1's changes are overwritten and all sorts of unhappiness ensues after that.

So far, what you are describing for symptoms sounds like a working folder being shared. Without seeing it in action, I'm having a hard time telling what's where with this. What I would recommend from this point is performing a Get with the Overwrite option on the server, and let me know your results.

[eday69]

Hi,
I'm the other developer in this sinario and I wanted to explain a little further how we have it set up. I don't believe we are sharing working folders.

I have my Vault Client on my workstation and have my working folder set to c:\Inetpub\wwwroot\recreationapplication so the working folder is on my local pc. Our other developter has it set up the same way with a working folder kept locally on his pc.

The server has a working folder set to D:\Inetpub\RecreationApplication this is the live site that our staff uses to run the application.

I will check out a file, make a change, build and then check back in. I'll go to our application and the change won't show up, so I will then log into the server and open the vault client and see the file says needs merge. I will do a get latest on that file and it will change to renegade. I then go and look at the application and the change will have been made, but the file still says renegade. We are also using a shadow folder if that matters.

We ran into an instance where some users received a bad file somehow so we went in and tried to do a get latest with overwrite on the application only to have our .sln file go "missing" crashing the entire application until we could point it back to the .sln file. That seems to take care of the renegade status if you do a get latest with overwrite, but usually when we try that things crash or people get files that are checked out on our local systems, but never uploaded because they aren't working.

We can definetly try doing a get latest with the overwrite option, but that will take some time because we will do it on individual files to prevent the entire application from going down. We just wanted to make sure we had things set up correctly and if not we need to fix so we don't get renegade files all over our application.

I've also taken a look at the log files, but I don't see anything there that would indicate anything is wrong.
Thanks, Erika

[Beth]

Is the shadow folder and the working folder for the server pointing to the same location?

[eday69]

Yes they point to the same location.

[Beth]

That will still show some goofy things, because the file is essentially still getting changed without a checkout. If shadow folders isn't copying something to disk that you need, then we will need to discuss your shadow folders at some point. Anything that changes the files in a working folder without the client being the one to manage it will show up as strange statuses that don't make sense.

As far as why it had Needs Merge and then went to Renegade after a get, that's hard to say, because there is the potential for the shadow folders to have been updating as well. Having both point to the same location is working in a way that the software wasn't intended to work in. Using client statuses with a working folder pointed to a shadow folder as a means of identifying the state of the file in the shadow folder won't work very well, plus, I can't guarantee that this won't have some affect on your shadow folders.

What might help here is if the client on the server ran in CVS mode and then use the Show Differences function to compare what is in the shadow folder to what is in the Vault repository. Go to Vault Tools - Options - Concurrent Development Style and click CVS mode. There is still a chance that you could see Needs Merge statuses, but you shouldn't have to worry about Renegade statuses. When you want to see if the shadow folder updated, then you should right-click the file or folder in Vault, select Show Differences, and choose the option to compare to the current version in the repository.

[bboland]

Thanks for the help Beth.

We will apply this change to run the client on the server in CVS mode and let you know if this takes care of the renegade file problem that we are having.

Thanks so much for taking the time to help us through this.

Brent

[Beth]

If this continues to give you trouble, then I would suggest we take this offline so I can take a closer look. At that point you can send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread and we'll pick up from where we left off.

[bboland]

Sounds good. Thanks again Beth.

[Beth]

You're welcome.