Files stuck on "Renegade" status

[craigr]

Just started using the new CPC on OS X. Thanks for doing this version.

I was previously using Vault (version 5) in a Windows 8 VM on my MacBook. So I have a working directory with all the latest code in it. When I installed the CPC I set the working folder to the same folder. It doesn't know what the status of the files are when you do that, which is fine. Over the course of a few days I discovered I have five unrelated files that Vault says were "Renegade" status (it may have said "needs merge" first; I don't remember). I compared these files to the current version in the repository and each says it is the same. I tried "get latest version" on those and it made no difference. I told it to overwrite changed files, and it didn't matter. Still "Renegade". I checked them out and checked them in. Still Renegade.

Tonight I deleted the renegade files from my working folder and did "get latest version" on them from Vault (which was accurately showing them as "missing"). They were downloaded from the server and immediately show up as "Renegade".

I have been editing and checking in other files; it is just these five that refuse to cooperate. Any ideas?

[Beth]

You have two possible things going on here.

1)

set the working folder to the same folder

Vault CPC isn't designed for other Vault clients to share working folders. Each has their own cache to compare to that working folder, and the statuses are based off of that comparison. There is no way to make the cache sync up.

2) EOL for a Mac and Windows are different. There is no way to sync those either. If you are no longer using the Windows VM, then you'll just clear your Vault client cache on the Mac, perform your Get again with the CPC and then check the status.

If you pick up using the Windows VM again with shared working folders, the issue will come back.

[craigr]

This problem seems to have resolved itself. When I checked today, the files were marked as "Needs Merge". I just got the latest version of each and everything is fine. Weird.

[Beth]

You might want to do a Diff against the version in Vault just in case there are changes you need to merge into the file you have.

[craigr]

This is happening again.

I had several files checked out and was working on some of them. I accidentally closed the CPC at some point during the day, so at the end of the day when I went to check in my work, I re-launched the CPC. Now every file I had checked out and have changed is marked "Renegade". I can't check in my changes because Vault believes the files are not checked out. I can't check the files out because Vault says they're checked out to a different location. But the files only exist in this project, I'm the only one working on them, they're only in one folder on my single Mac, and the location Vault says is "different" is the working folder for the project -- that is, yes, they're checked out, but they're checked out to me in the same folder that they've been modified in.

I am not using the Windows client any longer -- haven't used it on this project for a long time. And I've been successfully using the CPC with this project for months.

One of the other symptoms of this problem is that my "pending change set" list is empty. I've seen this happen before when I exit the client and re-enter it later.

I should note that I tend to leave the client open constantly on my MacBook. I rarely close it. This is one reason -- it fails when I close and re-open it.

I have backed up my changed files to Dropbox just to have a backup of my work. Suggestions??

[Beth]

I haven't been able to make this happen.

Does your working folder ever change?

Are multiple users using the same working folder?

In your Vault CPC Preferences - Local Files - Cache Location, what path do you have for the cache?

[craigr]

OK I'm starting to get pissed off now. I spent most of a day doing the following: I had several files checked out. The changed ones were marked as "Renegade" by Vault. I logged into the Vault server as administrator and undid all my checkouts. I renamed my working folder so that I had a copy of my changed files but no working folder anymore. I went into Vault and did a "get latest version" into my now non-existent working folder. This re-created my entire project from nothing and gave Vault a chance to recreate whatever indexes and caches it may have previously been using.

I then manually compared all the files in my new working folder to the copies of the files in my old working folder. When I found changes I checked out the file from Vault and copied the changed version into the new working folder, then checked those in. Like I said, that took most of a day. That was about a week and a half ago.

Today I launched Vault and discovered, once again, that it is referring to all my changed files as renegades.

To answer your questions: I do not change my working folder ever. The only change is what I described above. But as I described, nothing changed between yesterday (when it was working) and today (when all my changed files are marked as "renegade").

I am the only person working on this project. I am the only user on this laptop.

For Cache Location, I have selected "Store in User Local Settings Folder" (I don't think I have "selected" that -- I have never been here before. It must be the default.)

I'll stop now before I accurately describe what I think of this very expensive and non-functional software.

[jclausius]

craigr,

Sorry to see the frustration level building. I was looking over this entire thread to see if we missed something, and have a couple of questions:

- Do you happen to use the option for CRC file detection for file modification? (User Preferences-> Local Files -> Detect modified files using CRCs...)

- Is this behavior being seen with Vault 9? Or are you still on Vault 8?

- Is the file system where the working folders are located case sensitive? By default the OS X file system is case *insensitive*.

[jclausius]

criagr,

When you get a chance, do you think anything would be playing with either the Mac's host name, your user login, or the _sgvault locations (User Preferences -> Local Files -> Cache Location)?

To determine if a file is checked out, 3 things come into play, machine name at time of check out, path location of working folder, and user login. If one of these things have changed, it is possible Vault Client thinks the file is checked out to someone else or on a different machine, and if the file has been modified, it would show up as Renegade.

Other than that, the CRC option question mentioned above is also in play as there was a problem related to using that option in Vault 8, which was addressed in Vault 9.

[craigr]

I have CRC file detection turned on. That must be the default; I don't remember ever messing with that.

I am using Vault 8.

Working folder is on my local hard drive under OS X. I agree that it is case insensitive (TEXT.txt and text.txt are the same file). I don't change it ever, because I've done that before and Vault can't figure out what's changed and what's not.

Machine name: We may be on to something here. The renegade files are checked out to users-macbook-pro.local/users-macbook-pro.local (which matches my host name in System Preferences > Sharing except for capitalization). Files I checked out and edited yesterday are checked out to users-mpb/users-mbp.

I'm not finding exactly this problem when I google it, but it looks like the machine name / host name can change depending on the network. So could that be the problem? I move between three networks constantly. I just did a checkout using each of those three networks and they all show the file as checked out to users-mbp/users-mbp even though System Preferences says my host name is users-macbook-pro.local. I'd have to think about it but perhaps I checked out the renegade files while connected to a different WiFi network (I was working from a different location over Christmas break). Would this be characteristic of the problem?

And regardless, how do I resolve it? When I look in System Preferences > Sharing it says my local hostname is users-MacBook-Pro.local but when I check out files and check Properties, it says they're checked out on users-mbp/users-mbp.

Based on all of this, I believe the case could be made that it is a bad idea for Vault to use this as an identifier for the machine. The MAC address might be better, but even that is arguable (I've had to try to solve the "unique machine identifier" problem myself in my own code and run into these issues).

[jclausius]

And regardless, how do I resolve it? When I look in System Preferences > Sharing it says my local hostname is users-MacBook-Pro.local but when I check out files and check Properties, it says they're checked out on users-mbp/users-mbp.

That would explain a lot.

Unfortunately, there's no easy fix that you can do with any of the released clients as is. The machine/domain code based comes from the system, and if the system is constantly changing the string, then that is a problem.

Would you be willing to work in "Edit/Merge/Commit" mode? You wouldn't check out files, but instead let the client track changes you make to files within working folders and then place those changes in your pending change set. This takes the machine/domain string out of the equation. If you want to go this route, you'll need to change the 'Concurrent Development Style' in User Preferences, and most likely do a fresh get or remove the read-only flags on all files.

Again, this would be about the only work-around as we'll need some time to come up with a possible solution.

[craigr]

I'm normally not a fan of the Edit/MergeBadly/CommitCorruptedSource mode of source code "control" but given that I am the only developer on this current project it should be relatively safe. I'll give that a try.

Any thoughts on how to avoid this? Any idea where the users-mbp host name is coming from, given that System Preferences says my host name is users-macbook-pro.local? What system call are you making to get the host name?

[jclausius]

With the Windows GUI client, the string is formed by using two parts: System.Environment.MachineName and the WMI domain (within .NET).

For the Vault CPC, the string is formed by using : java.lang.System.getenv("USERDNSDOMAIN") and System.Net.Dns.GetHostName() (within Java)

-------------

With this info, you might be able to control the user name by setting an environment variable or possibly defining it within the vault-cpc.ini file within the App bundle, but the DNS GetHostName() may require some more research on your specific configuration to determine why it is changing.

[Beth]

We are working on this issue, but will need to discuss this further offline. If that's ok with you, could you send an email to support at sourcegear.com?

[jclausius]

@craigr,

Be on the lookout for Vault 9.1 which will let you use a user/hostname alias which can be used to override system information which seems to change from day to day.