问题
I am playing with the gated check-ins using an almost empty workflow, just to understand the inner workings.
Here is my scenario:
- Make a change.
- Check-in, triggering the gated check-in - the workflow does nothing.
- Go to the agent associated with the gated check-in and play a bit with the shelveset - see below.
So, I have created a new file (1.txt) and checked it in. The change is recorded in a new shelveset and now I am going to the agent and first make sure that no changes are there and that the shelveset is available:
PS D:\tfs\DFGatedCheckInTest2> tf status /recursive
There are no pending changes.
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt -ErrorAction SilentlyContinue
PS D:\tfs\DFGatedCheckInTest2> tf history ..\..\..\ /version:T /stopafter:1 /recursive /noprompt
Changeset User Date Comment
--------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
105631 DAYFORCE\mkhar... 10/24/2014
PS D:\tfs\DFGatedCheckInTest2> tf shelvesets "Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov" /format:detailed
===============================================================================================================================================================
Shelveset: Gated_2014-10-24_12.09.49.4626
Owner : DAYFORCE\mkharitonov
Date : Friday, October 24, 2014 12:09:49 AM
Comment :
Adding 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf status /shelveset:"Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov"
File name Change User Shelveset
--------- ------ -------------------- -------------------------------------------------------------------------------------------------------------------------
$/DFDev/mark
1.txt add DAYFORCE\mkharitonov Gated_2014-10-24_12.09.49.4626
1 change(s)
So far so good - no changes, the file does not exist and the shelveset is ready. Now I am unshelving the shelveset:
PS D:\tfs\DFGatedCheckInTest2> tf unshelve "Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov" /noprompt
$/DFDev/mark/1.txt:
opened for add in CANWS212;DAYFORCE\mkharitonov
Unshelving add: 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf status /recursive
File name Change Local path
--------- ------ ----------------------------------------------------------------------------------------------------------------------------------------------
$/DFDev/mark
1.txt add D:\TFS\DFGatedCheckInTest2\1.txt
1 change(s)
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/24/2014 12:16 AM 0 1.txt
Again, everything is as expected - the status command shows the right pending change and the new file is created. Next I check in the shelveset:
PS D:\tfs\DFGatedCheckInTest2> tf checkin /shelveset:"Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov" /bypass /force
Changeset #105632 checked in.
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/24/2014 12:16 AM 0 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf history ..\..\..\ /version:T /stopafter:1 /recursive /noprompt
Changeset User Date Comment
--------- ----------------- ---------- ------------------------------------------------------------------------------------------------------------------------
105632 DAYFORCE\mkhar... 10/24/2014 Adding 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf shelvesets "Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov" /format:detailed
No shelvesets found matching Gated_2014-10-24_12.09.49.4626;DAYFORCE\mkharitonov
PS D:\tfs\DFGatedCheckInTest2>
Looks good - the file is there, a new changeset is added to the history and the shelveset is deleted.
However, and this part I do not understand, there are still pending changes:
PS D:\tfs\DFGatedCheckInTest2> tf status /recursive
File name Change Local path
--------- ------ ----------------------------------------------------------------------------------------------------------------------------------------------
$/DFDev/mark
1.txt add D:\TFS\DFGatedCheckInTest2\1.txt
1 change(s)
Why ???
The only way I see to get rid of this pending change is undo and get the new changeset explicitly:
PS D:\tfs\DFGatedCheckInTest2> tf undo /noprompt /recursive .
Undoing add: 1.txt
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt -ErrorAction SilentlyContinue
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/24/2014 12:16 AM 0 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf status /recursive /noprompt
There are no pending changes.
PS D:\tfs\DFGatedCheckInTest2> tf status 1.txt
There are no pending changes.
PS D:\tfs\DFGatedCheckInTest2> tf history 1.txt /noprompt
Changeset Change User Date Comment
--------- -------------------------- ----------------- ---------- ---------------------------------------------------------------------------------------------
105632 add DAYFORCE\mkhar... 10/24/2014 Adding 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf get /version:C105632
D:\TFS\DFGatedCheckInTest2:
Getting 1.txt
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar-- 10/24/2014 12:44 AM 0 1.txt
PS D:\tfs\DFGatedCheckInTest2>
And here I do not understand another thing. If I have undone the change, then how come 1.txt is still versioned? What am I undoing here?
And getting the new changeset rewrites the file or just changes its last modification time (from 12:16 AM to 12:44 AM), which is equally bad. Indeed, suppose I build a zillion files following the unshelve. Now they will be built again in the next gated check-in, because the last modification timestamps of the source files was bumped up by the tf get command. (A second tf get /version:C105632 does nothing, of course)
This is awful. I must be confusing things, because it cannot be like this by design.
Please, explain to me what am I getting wrong here.
回答1:
This is all about containers, shelvesets and workspaces.
- you create your file and commit it to a shelveset (container A).
- You then goto the build agent and get that Shelveset into the local workspace (container B)
- You then commit the shelveset (from container A to source control) the check in from Container A is succesful and Container A is deleted to reflect that the Gated Shelveset has completed it's life cycle (if it failed it would remain intact)
- You then go back to the Agent workspace (Container B) which you haven't done any work to, since unshevling the file.
So at this point you have a New file that TFS has noted as being a pending ADD of (it doesn't exist in source control yet (no one else can access it, it only exists in your workspace (Container B), as you haven't manipulated it since the checkin from Container A)
Undoing the file is removing the ADD for the file in your Workspace Not the same file that was commited from the shelveset, but now there is a file in TFS with the same name as the one that you have in your local workspace (container B). so TFS does what it thinks is right and replaces your local file with the one from Source Control.
If you are working with TFS2010 as per the Tag then this sound correct, you will be working with Server workspaces, so only Changes / pending edits that TFS has been notified of will be detected. In 2012 / 2013 local workspaces can be used which can detect changes in the workspace that have done by the user without TFS being notified.
来源：https://stackoverflow.com/questions/26541731/why-checking-in-a-gated-shelveset-does-not-effect-the-pending-changes