Renegade File Bug

This forum is now locked, since Gold Support is no longer offered.

Moderator: SourceGear

Locked
dwayne_davis
Posts: 34
Joined: Mon Jan 26, 2004 5:12 pm

Renegade File Bug

Post by dwayne_davis » Fri Jun 11, 2004 11:33 am

I'm having a problem with the new install of Vault that we have. We're using 2.0.3, with VS IDE.

For one of our developers, there are a number of files marked as Renegade. The reason for this is unclear, as he has not checked the files out, nor did he change their 'Read Only' status. They have not been edited (by him in his working folder), but have been modified (in the repository) by other developers.

Now that they are renegade, Get Latest through the VS.IDE does nothing with these files. Automatic merges do not occur and we get a message that states that it is unable to perform an Automatic Merge. Get Latest through the Vault GUI sometimes seems to overwrite the file (no merge), sometimes does nothing - no change to the file. We haven't figured out why yet.

The only thing that we can think of is that other engineers have made changes to these renegade files, but the engineer who is getting the 'Renegade' status made no changes. There are significant changes made to a number of other files, such that simply blowing away the directory does not work.

We've found a workaround - one by one, we check out the renegade file, then undo checkout. This works, but is crude. We just bought the vault licenses (this week, after testing it for a number of weeks with no problem) and are very concerned now that we've made the purchase.

As a test, we copied that developers working directory and contents to another machine, then tried the same changes from that machine, same user login. The problems still exist here, but they are not marked renegade. Even so, the 'Get Latest' through the IDE does nothing. 'Get Latest' through the GUI simply overwrites the changes (no merging actually occurs).

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri Jun 11, 2004 12:18 pm

A renegade file is simply one whose datetime stamp has changed, but the file is not checked out. Sometimes, files get touched by programs, and the user is unaware of it, and it causes the file status to go Renegade.

However, since Vault thinks the file was edited, doing a Get Latest doesn't overwrite it - it tries to merge the changes from the server to the client, and since there are no client side changes, the merge should always succeed, and result in the version that currently exists on the server. In theory, having an unmodified renegade file should be harmless. You can do a Get Latest with overwrite to clear out the renegade status.

If you are getting merges that are failing, send us the 3 files that are causing the problem (the baseline, the working version and the repository version). It is highly unlikely that the merge itself if failing - it is more likely that the user's options are set in a way that causes Vault to do something unexpected, or that there is a problem in the IDE component.

Note we plan to include a CRC check in a future release to determine whether a file is really modified. This is a very slow way to do it, which is why we didn't do it this way originally.

Some knowledge base articles might also be helpful:
Vault file status:
http://support.sourcegear.com/viewtopic.php?t=131

Get Latest options:
http://support.sourcegear.com/viewtopic.php?t=162

Get Latest From IDE:
http://support.sourcegear.com/viewtopic.php?t=782

dwayne_davis
Posts: 34
Joined: Mon Jan 26, 2004 5:12 pm

Post by dwayne_davis » Fri Jun 11, 2004 2:02 pm

Where would I find the baseline file? The previous version in the repository?

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri Jun 11, 2004 2:46 pm

It is the version that the client was at when you did the last Get Latest. It is stored on the client, but it is pretty well hidden in the state folder, so if you know the version on the server, you can pull it from there.

dwayne_davis
Posts: 34
Joined: Mon Jan 26, 2004 5:12 pm

Post by dwayne_davis » Fri Jun 11, 2004 3:03 pm

Unfortunately, we've already worked around this (this time) by check-out and undo check-out.

I do have a question about this timestamp issue, though. Is is safer to set the 'Set file time' option to 'Check In' in the Vault options, for all of our developers? We're wondering if somehow this played into this problem.

dan
Posts: 2448
Joined: Wed Dec 17, 2003 5:03 pm
Location: SourceGear
Contact:

Post by dan » Fri Jun 11, 2004 3:36 pm

File time options would be indepenent of this problem. The client will set the time according to the set time option, then if the time changes from that after the Get, it will mark it as Edited or Renegade.

Locked