content validation / checkin, checkout, "may changed&qu

matzen · Post by **matzen** » Mon Sep 13, 2004 1:06 am

Hi,

First of all I want to say that I really like vault. Even in a LAN is it much better for our requirements than any other version control I've tested. But as always there are some things I'm not so happy with (at the moment).

I've just mentioned that vault does not compare content to recognize that there was a change of a file but uses the file date and time. This seem to be also the case when there is a file that "may have been changed". Well IMHO the overhead to calculate an MD5-hash while check in is not so big. Also to calculate MD5-hashes on the client side is not a big problem (nor is it very expensive compared to the VPN/WAN requests done to get the information from the server). But it can solve many problems while working with the files and may suppress the message "file content may have been changed, do you want to overwrite?". This message is sometimes VERY "uncomfortable", because I always do the same action in this case: check manually the differences (mostly ther are no differences) and then overwrite.

We have a structure where some of our developers are working in a different time zone, so relying on file date/time is not a very nice feature for us. What happens if the developer does have a different system date/time than the server (2 days in the future/past) because of a time sync problem?

May be my problems with the date and time just disappear if you can describe in detail how vault handles file updates.

CU,
Sven Erik Matzen

dan · Post by **dan** » Mon Sep 13, 2004 8:00 am

Vault does handle the timezone problem - the server stores the dates as UTC and each client will convert that to their local time. Are you having troubles with this, or are you just concerned about whether it will work?

Also, Vault does check the contents of the file prior to checking a file in. If the contents did not actually change, then we follow option for how to handle unchanged files. This doesn't handle the case that you reported, which is that if you timestamp didn't change, Vault won't know that the file contents changed. You would have to explicitly check out the file for it to appear in the pending change set.

And, as Eric mentioned, we do plan to put in an option that will see if a file has changed based on CRC rather than datetime stamp.

Are there specific examples of problems you are encountering (other than the case where the file contents changed but the datetime has not)? I want to make sure that we are aware of all the specific problems you concerned about.

matzen · Post by **matzen** » Mon Sep 13, 2004 9:01 am

I was just a little bit concerned about whether it will work or not, because we had already problems in the past with VSS (there is an option to check changes by date, by checksum or by content). The problem there was that some of our developers didn't pay any attention to date and time on there pc at all, so some of the pcs had the wrong regional settings and others had dates in the past. The effect was that vss did store change dated in the past for current check ins resulting in a very strange history
(e.g. the the file was created after it was changed etc.).

dan · Post by **dan** » Mon Sep 13, 2004 9:09 am

Yes, VSS has this problem because it isn't a client-server app. All the clients directly write to the VSS data files, and it is the client timestamp that gets applied to the data.

Vault is client/server, and it is the server's timestamp when a file is add or changed that it stores (in UTC) in the database, so a lot of those problems simply go away in Vault.