Possibly newbie problem - so advanced apologizes if I'm not "getting it." but we're evaluating Vault and we've have three different episodes of rather massive loss of edits. I'm pretty sure it is operator error, but I thought I'd ask, just in case:
1. We've managed to have local files which are newer than the repository version. If they do not show as checked out/edited in the IDE, when you go to edit the file, Vault appears to Get Latest Version and thus overwrite your edits? We think we caused this by editing the file outside the IDE - in particular, by copying a newer version of the file onto the solution file. We're used to CVS which seems to do a diff in nearly all cases and thus protecting you from yourself... can we make Vault do this (if it doesn't already?).
2. We had a bad experience with a user who used his Vault user name on two separate machines with separate trees of the same product. We're wondering if Vault supports this configuration? Is the status information stored per-user or per-user/per-machine or per-destination directory? Are there limitations on using your vault user name across machines? Similarly, can you use your vault user name from multiple locations on a local copy which is a file share?
3. We had a user who took his laptop home, did editing at home, and then when arriving at the office to check-in the next morning, somehow managed to lose all the edits? Is there anything special one should do when frequently working offline?
Bottom line: I think all of these things might be related... It seems that Vault is willing to perform operations without first diff'ing the files in question. Is that correct? Can we turn that optimization off to make it more like CVS?
Lest you get the wrong idea, we really like Vault - if we can figure this out, we'll definitely be happy campers (and customers!).
Thanks and apologies for any stupidness exhibited herein
Lost Work?
Moderator: SourceGear
Re: Lost Work?
We do support a "CVS mode" (options->Concurrent Development), in case you are not aware of those options already. However, CVS mode and the IDE integration component are not very compatible, because the IDE wants you to checkout files before editing them,and sometimes even determines that a file is checked out because it is read-writechrome wrote: 1. We've managed to have local files which are newer than the repository version. If they do not show as checked out/edited in the IDE, when you go to edit the file, Vault appears to Get Latest Version and thus overwrite your edits? We think we caused this by editing the file outside the IDE - in particular, by copying a newer version of the file onto the solution file. We're used to CVS which seems to do a diff in nearly all cases and thus protecting you from yourself... can we make Vault do this (if it doesn't already?).
I might need more specific info to understand this a bit better. Any file that is edited on your local machine could be considered "newer" than the repository version. Are you referring to a status of "More Recent"? This usually means the file has been pinned to a previous version, and you have a more recent version locally than the new pinned version in the repository.
If you don't use IDE integration, CVS mode should work fine. You can edit the file anywhere you want, then go to the Vault GUI client, and files that have been modified will show up automatically (after a file scan of your working folders)
Vault supports using the same user on different machines, and even the same user on the same machine for different working folders. The status info is stored per user per machine per working folder. However, this breaks down if you use the same working folder for multiple client instanes (e.g., have the same or different users on different machines using the same working folder). Each user/machine will have state information about the working folder stored in their own "cache", and if one person is editing the working folder, the other person's state info is not being updated, and wacky stuff will probably start happening.2. We had a bad experience with a user who used his Vault user name on two separate machines with separate trees of the same product. We're wondering if Vault supports this configuration? Is the status information stored per-user or per-user/per-machine or per-destination directory? Are there limitations on using your vault user name across machines? Similarly, can you use your vault user name from multiple locations on a local copy which is a file share?
Usually when people report their files being overwritten, it is because they either
3. We had a user who took his laptop home, did editing at home, and then when arriving at the office to check-in the next morning, somehow managed to lose all the edits? Is there anything special one should do when frequently working offline?
1) They did a Get Latest, and told Vault to overwrite the changes or
2) The status of their file in Vault was Unknown, which means Vault has to overwrite the file to get a baseline, to know when the file becomes edited. Any file not retrieved by Vault is considered Unknown (and yes, we do plan to make this better in future releases, to check the contents of the file against repository versions).
Any time Vault overwrites a local file, it backs it up in a _sgbak folder in the working folder, so any lost changes can always be retrieved.
But, in answer to your question: No, there isn't anything special that should happen, other than checking the default vault for the Modified Local File option.
Can you explain what you mean by diffing files before doing operations? I want to make sure I understand before claiming Vault does thisBottom line: I think all of these things might be related... It seems that Vault is willing to perform operations without first diff'ing the files in question. Is that correct? Can we turn that optimization off to make it more like CVS?
Thanks for you comments,
Thanks, Dan. I need to digest your excellent reply and try a few more things. As I mentioned, we really want this to work (and have only a 2 more weeks on our eval )
By diffing first I mean to never trust any local status (whether known or unknown) when doing a Get Latest. Instead, to always do a contents comparison to verify a local file overwrite. I believe you mentioned this desirable behavior in your reply:
By diffing first I mean to never trust any local status (whether known or unknown) when doing a Get Latest. Instead, to always do a contents comparison to verify a local file overwrite. I believe you mentioned this desirable behavior in your reply:
Any file not retrieved by Vault is considered Unknown (and yes, we do plan to make this better in future releases, to check the contents of the file against repository versions).