View history confusing?
Moderator: SourceGear
View history confusing?
When I make a change to a Win form UI element the change is made to the designer code file. When I check the form in and do a history it looks at the form code file and not the designer code file history. So this leads me to believe that in fact the changes to the form were not comitted when I checked it in. I assume this is by design but it can cause confusion. This happens at the project level as well and there is no easy way that I know of to see what the most recent history is (files) for a project. My confidence in this product has been an issue because of the Renegade files issue that I go through all too frequently so that is why I noticed this as I now explicitly check to see that all files are in fact checked in and that their is a history entry with the expected date time value.
If I wanted to go back to a previous version of the Win form and since the check in history for the changes made only appear if I view the history of the designer code file how would I do this?
Right click on form in IDE -> View History (shows very old check in as no changes have been made to the form code file but rather all changes were made to the designer code file)
It seems like if I make a change to a file that is part of the form (designer, resx, etc.) that the parent form file should reflect this fact when I do a view history since I did the check in on the form.
Right click on form in IDE -> View History (shows very old check in as no changes have been made to the form code file but rather all changes were made to the designer code file)
It seems like if I make a change to a file that is part of the form (designer, resx, etc.) that the parent form file should reflect this fact when I do a view history since I did the check in on the form.
On your first post, VS takes care of saving to the files on disk your changes, and sends the command for Vault to check it in. Vault will then just grab what is on disk and check in the changes it sees.
If you are getting renegade files all the time, that would indicate to me that things are happening to the files on disk without being checked out in Vault. This could be due to not opening the entire solution in Visual Studio, but instead going to disk and editing some files, or it could be due to the bindings between Visual Studio and Vault being messed up. This part should be looked into more and is probably the base reason for the issues you are having.
A big piece here that will make a difference is if you set a Working Folder in Vault. When using IDE integration, the place where Visual Studio places your files is your working folder, so you do not need to set that in Vault, or if you do, you have to set it to match Visual Studio and nothing else. You will have lots of problems if you have conflicting working folders.
If you are getting renegade files all the time, that would indicate to me that things are happening to the files on disk without being checked out in Vault. This could be due to not opening the entire solution in Visual Studio, but instead going to disk and editing some files, or it could be due to the bindings between Visual Studio and Vault being messed up. This part should be looked into more and is probably the base reason for the issues you are having.
A big piece here that will make a difference is if you set a Working Folder in Vault. When using IDE integration, the place where Visual Studio places your files is your working folder, so you do not need to set that in Vault, or if you do, you have to set it to match Visual Studio and nothing else. You will have lots of problems if you have conflicting working folders.
On the second part, is the file that is a part of that form actually changed? Vault only tracks file changes and checks in changes (in the form of deltas). The entire file itself is only uploaded once to the database. Vault tracks changes through the use of the client side cache which compares the baseline of the file checked out to the file in the working folder. When it does the compare and sees a change, it uploads a delta that represents just that change. If there is no change, then no delta is uploaded.
Again, if different folders are set between Vault and VS, it could be looking at the wrong location then. You could be making changes to a file that is in one location on disk and then during the check-in, if the working folder points to somewhere else, it would be looking at a file that had no changes and then not check in a delta. Visual Studio has to run the show with the working folders.
Again, if different folders are set between Vault and VS, it could be looking at the wrong location then. You could be making changes to a file that is in one location on disk and then during the check-in, if the working folder points to somewhere else, it would be looking at a file that had no changes and then not check in a delta. Visual Studio has to run the show with the working folders.
The association made between the form file and its designer file is made by Visual Studio, not by Vault. Vault doesn't know anything about it. From Vault's viewpoint, there are two files, Form1.vb and Form1.designer.vb, and when they're checked in, Vault has no way to know that changes made in Form1.designer.vb were done by Visual Studio rather than you.
One thing you can do is to keep your list of files (in the Vault client) sorted by date rather than filename. Then it would be immediately apparent which files had most recently changed, so you would be able to see which files to check history on.
Regards,
One thing you can do is to keep your list of files (in the Vault client) sorted by date rather than filename. Then it would be immediately apparent which files had most recently changed, so you would be able to see which files to check history on.
Regards,
David Thompson
JELD-WEN, inc.
JELD-WEN, inc.