Checked Out File appear as renegade

JoeBoy · Post by **JoeBoy** » Thu Oct 28, 2004 1:54 pm

I have a user who checked out a bunch of files using the vault gui client and then modified a few of the files.

The status of the files in the vault client is Renegade instead of edited. The Check in and undo commands are not available.
The files indicate that they are checked out exclusively.
We tried to check the file out again and received a message indicating that the files are already exclusively checked out.

Any ideas on what could be the problem here?

dan · Post by **dan** » Thu Oct 28, 2004 2:39 pm

Is it possible the files are checked out on a different machine? If so, they would appear checked out to you on this machine, but can only be checked in from the machine where they are checked out from. The Checkout location in the properties would tell you this, or turn on the Check Out Location file list column in Tools->Options->File List Columns.

JoeBoy · Post by **JoeBoy** » Mon Nov 01, 2004 12:51 pm

I just checked the Developer's PC.

The properties of the file in vault indicate that it is checked out to his PC. Also, I verified that the check out path does match the working folder path.

Is there any way as an admin that I can force an "undo Checkout" so that I can get this guy back up and running?

Regards,

-- Joe

dan · Post by **dan** » Mon Nov 01, 2004 2:44 pm

Yes, the Admin Tool has an Undo Checkout pane, which allows you to undo any current checkouts for a given file.

kasti · Post by **kasti** » Wed May 25, 2005 1:40 am

To recap, we also regularly see this problem (currently using 3.0.7):

- user A has checked out certain files
- user A has seen the file as checked out in the gui client
- after modifications to some files, trying to do a checkin
- user A does not see on his client that the files are checked out (status renegade)
- checking out again will show failure message "file already checked out"
- every other user can see the file as check out by user A
- undo checkout for user A is greyed
- deleting cache directories of user A does not help

A way we can recover from this is:

- go to the admin tool
- select user A
- switch his "default user rights" (e.g.: all 3 boxes checked to all 3 boxes unchecked or the other way round)
- do a refresh of the client (F5)

-> files will now appear as checked out for user A

Bye,
Herbert.

dan · Post by **dan** » Wed May 25, 2005 8:27 am

Is the checkedout file a shared file, or in a folder that is a shared folder?

Guest · Post by **Guest** » Mon May 30, 2005 5:52 am

Hi Dan,

No, in the last case where we had this problem the file / folder was definately not shared. There were about 50 files in a directory. 5 of these were checked out and modified. All those 5 files appeared as Renegade.

Bye,
Herbert.

dan · Post by **dan** » Mon May 30, 2005 1:51 pm

This is a mystery.

I guess the next step is to turn on client logging. See http://support.sourcegear.com/viewtopic.php?p=7806 and enable the checkout loggin class only (otherwise there is too much info in the log to be useful). That may reveal information that will be useful.

kasti · Post by **kasti** » Wed Jun 08, 2005 7:58 am

Hi there,

I uploaded a gui client logfile to your ftp server/incoming/herbert_vaultclient_renegade.rar.

I did a few refreshes (f5). Then I changed the default user rights and at 15:39:53 I did another refresh. After that all the files changed status from renegade to edited.

Bye,
Herbert.

Post by **jclausius** » Wed Jun 08, 2005 12:41 pm

Herbert:

Can I also ask for your server's log file as well? I'd like to match the client log to the server log.

Thanks.

Post by **jclausius** » Wed Jun 08, 2005 12:48 pm

Herbert:

I'd like to ask some other follow up questions:

- At what point do the files go renegade? Just directly after editing them? After a refresh? Any other event?

- When the file goes to renegade, does the checkout listing still show the file checked out to user A?

- Is this user on a laptop? Or is the user changing the machine's DOMAIN or hostname?

- When you delete the cache files, are all of the Vault clients (IDE, GUI) shut down? Or are you deleting them while Vault is still running?

Post by **jclausius** » Wed Jun 08, 2005 1:16 pm

Herbert:

One other thing I noticed. Can you verify both the Server version and client version? The Log file you uploaded is from a Vault 3.0.6 client.

kasti · Post by **kasti** » Thu Jun 09, 2005 4:28 am

Hi Jeff,

Here is some more info. Yesterday it happened to 3 users. So it seems to become more frequent as we start using vault more intensive.

At what point it happens I can not really say. One instance today was:

- user A had files checked out in 3 different projects.
- this morning, they were all renegade
- i fixed the problem by changing default rights (file status went to edited)
- user A checked in files of 2 projects
- user A went to a meeting, after coming back he tried to check in the 3rd project but files were renegade again

->user A ensured me that he did not restart vault or do anything else besides checking in project 1 and 2 since my last fix (i checked server log and indeed there was no logout for that user during this time)
->i played around and found a simpler way to fix the problem by ending vault, deleting "CacheMember_CheckOutList" and restart vault (sorry about telling you that deleting cache files does not help, must have done something wrong)

some other info:

- the checkout listing is also empty for that user when the prob occurs
- it happens to laptop and desktop users
- changing domain etc is definately not happening, it also happens while a user keeps vault open
- the logfiles from yesterday were from a 3.0.6 user. Server is running 3.0.7 and it also happens on 3.0.7 clients (having servers/clients out of sync is a real problem for us, i have got a feature request on this that didnt get answered

http://support.sourcegear.com/viewtopic.php?t=3784

- the vault server log will not help, i checked and there is just login/logout info (log level: quiet). i will change this soon.

- i will still upload the "CacheMember_CheckOutList" file to your ftp server. One with the problem, one after deleting/rebuilding it (herbert_cache_renegade.rar). You will notice that there is a major size difference.

Bye,
Herbert.

Post by **jclausius** » Thu Jun 09, 2005 7:32 am

kasti wrote:- user A had files checked out in 3 different projects.
- this morning, they were all renegade
- i fixed the problem by changing default rights (file status went to edited)
- user A checked in files of 2 projects
- user A went to a meeting, after coming back he tried to check in the 3rd project but files were renegade again

Do you have a captured log here (from the start of the problem to the reset to the time after the meeting)?

kasti wrote:->i played around and found a simpler way to fix the problem by ending vault, deleting "CacheMember_CheckOutList" and restart vault (sorry about telling you that deleting cache files does not help, must have done something wrong)

That is re-assuring, as this is the expected behavior.

kasti wrote:- i will still upload the "CacheMember_CheckOutList" file to your ftp server. One with the problem, one after deleting/rebuilding it (herbert_cache_renegade.rar). You will notice that there is a major size difference.

Can you provide some more information related to the layout of the repository for user A? Is the path they are working on shared (either file or folder)? Has user A been denied a part of the tree? Any other information?

Post by **jclausius** » Thu Jun 09, 2005 7:49 am

Just reviewed some bugs.

A couple of items were fixed in Vault 3.0.3/3.0.4.

1) The file is shared, and pinned to an earlier version in the other folder.

2) Incorrect version in the source tree - In user A's client, the file reports a "remote" revision. What is that number? Now do a history on that file. What is the max historical version number?

Do either of these cases apply?

SourceGear Support

Checked Out File appear as renegade

Checked Out File appear as renegade

Checked Out Files appear as renegade