The issue is Vault changing the file modification date to the branch date when the file is branched. This was discussed previously:
http://support.sourcegear.com/viewtopic.php?t=2525
http://support.sourcegear.com/viewtopic.php?t=2616
http://support.sourcegear.com/viewtopic.php?t=1242
http://support.sourcegear.com/viewtopic.php?t=6245
http://support.sourcegear.com/viewtopic.php?t=5383
In some of those topics, it was said that this would be something under consideration for version 4 but it appears, as far as I can tell, that this has not been changed in version 4. Is there any chance that this will be changed at some point in the not-too-distant future? Thanks!
Branching & File Modification Dates
Moderator: SourceGear
Well, just an FYI, we've got lots of stuff waiting to be converted from VSS to Vault, and this issue is currently presenting a roadblock to doing so, because we can't have the file dates changing on a branch.
The problem is that when we go to create a build, we branch all of our code into the new build folder then modify whatever files need to be modified. Admittedly, it's probably not the best way to do it, but it's how things have been done here for years and I don't see it changing anytime soon. Old dogs, new tricks, you get the idea. In VSS we can look in a build folder and immediately see which files were changed in that build based on their modification dates. With Vault, every file will end up with the same modification date regardless of whether we've actually edited them or not.
Additionally, since we also store certain binaries in VSS, DLLs and so forth, with Vault we'd end up with DLLs getting new date stamps even though they may not have actually been changed in years.
Now, I know the argument is that by branching a file you're creating a "new" file, hence the updated modification date. But from our point of view, a product which presents itself as a VSS replacement should actually provide the same functionality as what it claims to be replacing. When we can't do with Vault what we could with VSS and get the same results, then it's not really presenting us with much of a replacement.
So as it stands, we're quite anxious to get our development code out of VSS and into something else, since it's only a matter of time before more of our VSS databases go corrupt on us. With VSS, database corruption seems to be more a matter of "when" rather than "if". We're all set up for Vault to be that replacement, but given this roadblock, we're at a point where discussions are beginning to take place regarding whether or not to start looking elsewhere. I'd personally hate for that to happen, since I think Vault is a good product, and since I've already put lots of time into converting our in-house tools to the Vault API. And I'm pretty sure you folks don't relish losing customers. So I guess what I'm saying is that sooner would be better than later, if it can be helped.
The problem is that when we go to create a build, we branch all of our code into the new build folder then modify whatever files need to be modified. Admittedly, it's probably not the best way to do it, but it's how things have been done here for years and I don't see it changing anytime soon. Old dogs, new tricks, you get the idea. In VSS we can look in a build folder and immediately see which files were changed in that build based on their modification dates. With Vault, every file will end up with the same modification date regardless of whether we've actually edited them or not.
Additionally, since we also store certain binaries in VSS, DLLs and so forth, with Vault we'd end up with DLLs getting new date stamps even though they may not have actually been changed in years.
Now, I know the argument is that by branching a file you're creating a "new" file, hence the updated modification date. But from our point of view, a product which presents itself as a VSS replacement should actually provide the same functionality as what it claims to be replacing. When we can't do with Vault what we could with VSS and get the same results, then it's not really presenting us with much of a replacement.
So as it stands, we're quite anxious to get our development code out of VSS and into something else, since it's only a matter of time before more of our VSS databases go corrupt on us. With VSS, database corruption seems to be more a matter of "when" rather than "if". We're all set up for Vault to be that replacement, but given this roadblock, we're at a point where discussions are beginning to take place regarding whether or not to start looking elsewhere. I'd personally hate for that to happen, since I think Vault is a good product, and since I've already put lots of time into converting our in-house tools to the Vault API. And I'm pretty sure you folks don't relish losing customers. So I guess what I'm saying is that sooner would be better than later, if it can be helped.
We're sorry to see you're not migrating from VSS, but I see why this would be a roadblock.
This feature has been down for some time, but it's not a simple fix. We've been hesitant to make large changes which may cause instability within the Branching code. A change of this magnitude will require changes to the Branch API, GUI changes on the Branch dialog, new options on the command line, as well as making sure the new branch API is backwards compatible.
In any case, we want to be responsive to our customers. I've moved this up in priority. If things proceed according to plan, I'm hopeful we can implement this in Vault 4.0.6 / Fortress 1.0.6.
This feature has been down for some time, but it's not a simple fix. We've been hesitant to make large changes which may cause instability within the Branching code. A change of this magnitude will require changes to the Branch API, GUI changes on the Branch dialog, new options on the command line, as well as making sure the new branch API is backwards compatible.
In any case, we want to be responsive to our customers. I've moved this up in priority. If things proceed according to plan, I'm hopeful we can implement this in Vault 4.0.6 / Fortress 1.0.6.
Jeff Clausius
SourceGear
SourceGear
Hello again. Just wanted to check on this again. I just gave Vault version 4.1 a whirl and noticed that branching still updates file modification dates. I also noticed that the version 3.5.3 of the Vault API has added a bool branchWithOrigModTime parameter to it's ChangeSetItem_CopyBranch object, though it appears not to do anything. So I thought I'd check back to see if there is actually any chance of this being implemented in the not-too-horribly-distant future, or if I should just come to grips with the fact that it isn't going to happen.
Thanks!
Thanks!
Ok, cool. Thanks for the response. I keep checking each new release to see if this has been implemented, because once it is I will be jumping for joy. 
If you don't mind me asking, do you suppose this maintenance release might be available within the year? Not that I'm expecting a solid commitment or anything, but rather I'm just trying to get a rough time frame. The reason being, I'm about to embark on developing an application that would give us something of a workaround. Basically, it would branch code files, because it's not that important to us whether those dates get updated, but with binaries it would retrieve and add rather than branch. Believe me, I'd love to just get those binaries out of Vault and thereby avoid this problem altogether, but that "old dog learning new tricks" cliche is appropriate to this situation.
Anyhow, if this was going to be implemented in the near enough future that I could avoid wasting a whole lot of time on this application, I could just hold off migrating our stuff from VSS a little longer and be a very happy fellow.
Thanks again!
If you don't mind me asking, do you suppose this maintenance release might be available within the year? Not that I'm expecting a solid commitment or anything, but rather I'm just trying to get a rough time frame. The reason being, I'm about to embark on developing an application that would give us something of a workaround. Basically, it would branch code files, because it's not that important to us whether those dates get updated, but with binaries it would retrieve and add rather than branch. Believe me, I'd love to just get those binaries out of Vault and thereby avoid this problem altogether, but that "old dog learning new tricks" cliche is appropriate to this situation.
Anyhow, if this was going to be implemented in the near enough future that I could avoid wasting a whole lot of time on this application, I could just hold off migrating our stuff from VSS a little longer and be a very happy fellow.
Thanks again!
Workaround
For those interested in a temporary workaround to "reset" the file timestamps to their last modification date/time:
1. Branch the code
2. Get the latest from mainline and the new branch
3. From Windows Explorer, copy the mainline working folder on top of the branch working folder
4. This effectively resets the timestamps to the mainline
5. In the Vault client, set the Options for unchanged files to "Check in"
6. Check in the branch
This is a little more work but does the trick.
1. Branch the code
2. Get the latest from mainline and the new branch
3. From Windows Explorer, copy the mainline working folder on top of the branch working folder
4. This effectively resets the timestamps to the mainline
5. In the Vault client, set the Options for unchanged files to "Check in"
6. Check in the branch
This is a little more work but does the trick.