Vault client get marking all files "Renegade"

Pawan · Post by **Pawan** » Fri Oct 29, 2004 12:20 pm

Hi,

For some reason, on our build machine, all the files which we get using the command line utility are being marked as "renegade" even though we delete all the files on the disk and get them using the commandline.

Is this a known bug? We use the following options:

-makewritable -merge overwrite

when doing a get on the build machine. Doing a compare on the files after the get shows that the files are identical.

Thanks
Pawan

sterwill · Post by **sterwill** » Fri Oct 29, 2004 2:04 pm

Vault 2 uses filesystem modification dates to determine whether a file is modified (Vault 3 offers an option to use CRC32). It sounds like the dates on the files are changing (perhaps a build tool is touching the times), or the command-line client isn't storing the "modification time at last get" correctly in its state files.

Are you verifying the status (Renegade) through the Windows Forms or the command-line client after the get?

Also, as an aside, we recommend that build systems use the -destpath option to the Vault CLC, which tells it to use a "non-working folder". You can't check in changes from a non-working folder, which isn't an issue on a build machine. Since there are no baseline files stored, and the code path for getting files to non-working folders is much simpler than for working-folders, the overall reliability goes up. This can help insure your builds are always exactly what's in the server's repository.

Pawan · Post by **Pawan** » Fri Oct 29, 2004 2:17 pm

We use the GUI client to verify if the files are renegade.

I am getting around the problem by removing -destpath option from the commandline and the renegade problem went away. If I use -destpath and assign it to get files in exactly the same folder as the "working folder", all the files are getting marked as renegade.

It seems like a bug to me.

-Pawan

sterwill · Post by **sterwill** » Fri Oct 29, 2004 3:14 pm

It sounds like Vault is working properly. Folders retrieved using -destpath should not be used as a working folder in any Vault client. They lack all of the information about file versions and times that Vault needs to determine a file's status. When a Vault client is told to use a disk folder that was previously retrieved as a non-working folder, it will assume that the files were put there as part of its own operation (which may have happened long ago) and expect the wrong dates.