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).
Renegade File Bug
Moderator: SourceGear
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
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
-
- Posts: 34
- Joined: Mon Jan 26, 2004 5:12 pm
-
- Posts: 34
- Joined: Mon Jan 26, 2004 5:12 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.
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.