As you can see this leads to a situation where code changes are lost and has caused us a number or problems,OK. This is what I think happens – I’m not sure all these steps are necessary to reproduce but it is what I did:
You have a file checked in to the repository. Let’s call it FileA. In Visual Studio (not sure this is important or not):
1. Rename File A to FileB.
2. Make changes to FileB.
3. Add a new file called FileA.
4. Try and check-in and you get an error about duplicate ID’s.
5. To get round this error, check-in the rename on its own first.
6. Now check-in any remaining pending changes.
The changes you have made in step 2 above are NOT in the repository, but they remain in your working copy.
If you do a get latest version, FileB is renegade (even though nothing has been changing this file since step 2 except Vault). To avoid having the changes overwritten in your working copy and to update the repository you need to checkout FileB without overwriting, then check-in.
For me there are 2 bugs here:
1. The first check-in at step 4 should work. It is a perfectly reasonable thing to do during development. This is however relatively minor as it doesn’t cause loss of any code changes.
2. The check-in of a rename in step 5 should include any changes made to the renamed file OR there should be a separate pending “edit” change on FileB so there is no way to lose your changes to this file in step 2 above. This is a serious bug as it happens silently and it effects the integrity of the code in the repository.
We are running VaultPro V8.0.0 (30192) and visual studio pro 2013 v12.0.31101.00 Update 4.
A fix for this would be greatly appreciated.
Rgrds Ian