In general, I use an automated environment to create Releases, the proverbial Build Machine. The Build Machine is script driven (labeling, getting, building, and creating the installation.
Unfortunately , when I run the Get script, which includes the following:
vault getwildcard $%VAULTROOT% *.* -setfiletime checkin -makereadonly -norecursive -destpath %ROOTPATH%
The GUI tells me that my files are now Renegades. My Vault Server is located in another timezone (+2 hours), the timestamps of the files is equal to the check in time after the script runs; however, the GUI knows that I am -2 hours, it seems to do the math and determine that all of my files are Renegades.
NOTE: After doing a recursive & overwirting Get Latest with the GUI, my file timestamps are +2 hours; therefore, when the GUI does the math it determines that the files are NOT Renegades.
Suspect: The script's "-setfiletime checkin" does not seem to be taking different timezone into account.
Mixing + Matching the Client GUI & Scripts = Renegades
Moderator: SourceGear
Mixing + Matching the Client GUI & Scripts = Renegades
Dan in San Diego
Sorry for the delay on this - I was trying to reproduce it first.
It looks like the problem is that the destpath command line arg is being used as the working folder. The Vault command line client knows which working folders are associated with which Vault repository folders, so you don't need to specify the working folder.
Destpath should only be present when you want the files to go to a non-working folder. When files are being retrieved to a non-working folder, no state files are updated (that's the definition of a non-working folder - the files in it have a completely unknown state).
Since the working folder was specified as the non-working folder, it overwrote the files, but not any of the state information. So, files became Renegade (if they already existed), because their timestamps changed, or Unknown (if they didn't exist in the working folder), because they now exist there, but Vault doesn't know their state.
Removing the -destpath parameter should make it work as expected.
It looks like the problem is that the destpath command line arg is being used as the working folder. The Vault command line client knows which working folders are associated with which Vault repository folders, so you don't need to specify the working folder.
Destpath should only be present when you want the files to go to a non-working folder. When files are being retrieved to a non-working folder, no state files are updated (that's the definition of a non-working folder - the files in it have a completely unknown state).
Since the working folder was specified as the non-working folder, it overwrote the files, but not any of the state information. So, files became Renegade (if they already existed), because their timestamps changed, or Unknown (if they didn't exist in the working folder), because they now exist there, but Vault doesn't know their state.
Removing the -destpath parameter should make it work as expected.