One of our developers discovered something very strange in Gated Checkin Builds which seems to be a feature of Gated Checkins.
When launching a Gated Checkin, the solution in his Solution Explorer seems to go back to the last Version Checked in. After the build is completed Visual Studio shows an error or success message with the button in German called "Code aufnehmen" (in English: "Reconcile...")
After clicking he gets back his changes.
I know that in Visual Studio you can choose to revert your solution when shelving it. It appears to me that this is what Visual Studio does by default.
Is it possible to set Visual Studio or TFS to not revert after shelving for Gated Checkins?
Or maybe someone can tell me the reason why Visual Studio does it.
The whole process with Gated checkins is that TFS:
Constructs a Shelveset with all changes
Tries to Build the latest state of the codebase + this Shelveset &
If all succeeds, Shelveset gets commited into the repository
By default, TFS will revert the Developer's workspace into the last checked in during this operation. This can be changed with the following: By doing this, Developer can directly continue working, but once the build is over trouble & conflicts may arise when reconciling the local workspace.In general, gated builds should last as less as possible. If this principle is kept, the reaswonable way to proceed is to avoid setting the "Preserve"
option. If the Build last longer, than -say- 5 mins, it might be worth doing so. A very nice description of the Gated Checkin functionality can be found in this article by P.Carnahan.
Related
Why does this not behave as stated, or at least, how can I achieve the expected behavior?
When I do a "Save All" command (Ctrl+Shift+S), it is reasonable to expect my pending changes information to be saved to my workspace, but when Visual Studio crashes, it reverts to how it was the last time I exited Visual Studio gracefully (but with newly checked-out files included in the Pending Changes list).
This has caused me to lose my check-in notes and associated work items/etc. numerous times now.
To clarify, if I close Visual Studio normally, my check-in notes etc. are preserved for the next time I open VS, but if VS crashes they are not, therefore they are saved somewhere, thus the "Save All" command is not behaving as clearly stated by its name.
The problem here is that you need to distinguish between the state of your files and the state of the Visual Studio IDE.
"Save all" will only ever write the in-memory changes of the files down to the disk. It does not have anything to do with the check-in comments or linked work items. These are part of the state of the Visual Studio IDE. That state is only saved to disk when you close Visual Studio.
If Visual Studio crashes, its state is simply not persisted which is why you just loose the state, in your case the comment and associated work items.
Its the same with the size and position of the Visual Studio windows. If you move a window around and close Visual Studio the position of the window is saved. Next time you open it the position is restored.
This is particularly an issue if you have multiple instances of Visual Studio open. Closing an instance will overwrite the state that was persisted by closing another instance before that.
Unfortunately I'm not aware of any way to save the state of Visual Studio other than actually closing it. It's unfortunate but that's how it is.
Personally, I maintain a dedicated text file where I write my check-in comments and just paste those comments into Visual Studio before I do a check-in.
We do not use "Save All" to save unfinished work in TFS.
If you have work in progress that you cannot finish now so you want
a backup copy that is stored on your server and available to other
team members who might need to access it.
Or you just want to backup your code before leaving office at
evening.
Under both situation, you should use shelvesets to handle this.
You can move your pending changes to a shelveset on the server and
then clean your workspace. The shelveset saves and stores not only
your file revisions, but also the Comment, the list of Related Work
Items, and check-in notes (if you evaluate policies before shelving).
When you are going to resume to work, you could simply unshelve the shelvest, just make sure "Restore Work items and check-in notes" checked
Then you will not lose any check-in notes and associate work items even Visual Studio crashed. More details about the shelvest, please take a look at our official tutorial here: Suspend your work and manage your shelvesets
Update:
According to your supplementary , it's more related to Visual Studio's design of crash and recovery. Which seems not related to TFS part.
What we could do is using shelvest frequently to protect your data losing. After all, totally cash in visual studio won't happen very often. This will also help to make lose reduced.
TFS creates a shelveset when you suspend work in Visual Studios 2017. When you then resume the suspended work TFS deletes the shelveset. Is there an option to preserve shelvesets on the server when unsuspecting work?
All active Work Items and currently Pending Changes are considered In Progress Work. If the Suspend button is clicked, system will shelves the code along with references to the active Work Items, currently open files, breakpoints, etc.
Basically, the current state of Visual Studio is saved for later recovery. Modified files will be reverted to the Latest Version.
Then when you select ‘Switch’ or ‘Resume’ and the suspended work would be recovered along with the previous state of Visual Studio. The code can then be checked in. The shelveset will be deleted automatically.
If ‘Switch’ is chosen, then the current work is suspended before the selected work set is restored. After check-in is complete, then the previous work [for instance, 2 edit(s)] can be ‘Resumed’.
There is not any option to preserve shelvesets on the server when unsuspecting work. As a workaround you could first shelve your pending changes and work first, make sure check preserve pending changes locally, then suspend your work.
There will a shelveset which contain your previous work and record in server side.
I am getting the aforementioned error most times I unshelve from Team Explorer > Shelveset Details, but unlike this question, I have my workspace set correctly under my Pending Changes window. The weird part is that I am always able to unshelve after trying a second time without changing anything.
It didn't always do this to me, and it seems to not affect anybody else on my team. I've not messed with any settings that I can think of as being relevant either.
And yes, I've restarted my computer since it started happening.
Another thing it does is deletes all ADD changes upon reconciling after passing a gated check-in build.
Thanks.
Using VS 2015 Update 3 (version 14.0.25431.01) connected to TFS 2015 (version 14.102.25423.0)
According to your description:" it seems to not affect anybody else on my team". The issue should be a client side issue.
First,you could use another TFS account to unshelve Shelvesets on your develop machine. This will narrow down if the issue related your account or not.
Suggest you try to clear TFS and VS cache:
For TFS cache:
close all instances of Visual Studio on the client machine,
manually delete the corresponding Tfs client cache folder, and then
start Visual Studio
The corresponding Tfs folders to manually delete are as follows:
Tfs 2015: "%localappdata%\Microsoft\Team Foundation\6.0\Cache\"
For VS cache:
Delete the contents from the following folders
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VisualStudio
C:\Users\<<Your Alias>>\AppData\Local\Microsoft\VSCommon
If above not work, you could also delete the old workspace(back up local changes first), and create a new one. Then test it again, which should do the trick.
It turns out that opening the shelfset before changing my workspace from pending changes causes the issue. The solution is the change the workspace in pending changes before opening the shelfset.
I'd definitely call this a bug in VS since the shelfset viewer does not indicate which workspace it is referencing before unshelving.
I've been through all the Visual Studio Source Control documentation and so on but I can't find an answer as to whether it's safe to keep working in Visual Studio whilst it's doing a check-in?
We're using Visual Studio 2015 with Visual Studio Team Services source control.
Sometimes there's one or more files (like video files) that take a while to check in, sometimes an hour or more. I'm worried that if I keep working (specially if I work on the same files that are busy checking in) it'll corrupt the process.
Normally, it is safe as TFS won't check the changes again after you click check-in button. It just check in the changes you made before click check-in. So edit the file does not affect the check in process.
But in some case, for exmaple, the internet access is disconnected during check-in, then you click "Refresh" button to reconnect to TFS service. The changes will be refreshed too. That means the changes you made during checking is been included now. And there isn't any way to restore to the version that you'd like to check in.
So, you'd better avoid this as possible as you can and check in large files when you are not working with them.
I'm working in a big project in Visual Studio 2010. Often I must wait the check-in before doing simple test. How can I work with Visual Studio 2010 offline when TFS Server is available?
I'm not sure I understand your question 100%, but there are a couple of options depending on what you mean.
First of all, working offline is not possible with TFS 2010, but is available with local workspaces in TFS 2012 (overview in this article)
You say that you're waiting for check-in to complete. If you have a plain check-in situtation, then you have a couple of choices:
You can open a second instance of Visual Studio, and work while the first instance completes the check-in.
You can open a command prompt and use tf.exe checkin in your workspace directory.
If you have a gated check-in, then you can check the 'Preserve my pending changes locally', and you will be able to keep working on the changes until they have been validated and checked in. (further details in this article)
All that being said. A simple check-in should not take more than seconds. So if you're waiting a long time for a normal check-in situation, then you might have some performance/server issues.