This is my requirement.
I have a project that reference three DLLS from third party.
These dll's change. So I would like to get them checked in automatically without having to perform any manual task such as having to press the check in button in Visual Studio.
Once it is checked in TFS CI will take over make and build and run the tests.
My environment is TFS 2018 and Visual Studio 2017-2019.
I have spent enormous amount of time. trying to figure this out.
You can schedule tf checkin as a windows task. It can run every 10 mins or 1 hour the following command:
tf checkin /noprompt "PATH_TO_LOCAL_WORKSPACE_FOLDER" /recursive
If PATH_TO_LOCAL_WORKSPACE_FOLDER does not have changes, the command returns:
There are no pending changes matching the specified items.
No files checked in.
If the folder contains changes, the command check-ins, and returns:
The list with some files
Changeset #ID checked in.
Related
This relates to question,
TFS checkin error - could not find file
"When checking in my project I get the error:
Could not find file 'C\blah blah blah'.
I have a feeling this might be a file from an old project I deleted.
I have tried deleting my TFS connection and workspaces.
The Solution was:
This will happen when TFS has some changes staged that no longer exist on the file system. For instance, if you add some files in Visual Studio (which adds them to the changes list), delete them directly from the file system, then attempt to check in the changes, it will complain that it could not find the file(s).
To remove these changes from the list, you can open Source Control Explorer (View > Other Windows > Source Control Explorer) and either Delete the nonexistent files or right-click on the offending files and Undo Pending Changes.
You can also undo these specific changes from the Pending Changes panel in Team Explorer.
Follow up Question:
So my question is,
how do I conduct the equivalent of this in the TFS Server? It continuously happens multiple times on our team.
This works on a person's desktop, but whats the equivalent commandline in the TFS server, and can I incorporate this in my build steps?
You delete files from TFS in the wrong way. the TFS server doesn't know your local file system, if you deleted a file from your local folder the file still exists on TFS.
This is the reason for the issues and errors. if a developer wants to delete a file and he deleted the file from the local folder and then got the error Could not find file and to solve it he does "Undo pending changes" so the file still exists on TFS and when another developer see the file in his system he also deleted it locally and he also will get the error in the check-in.
So, if a developer wants to delete a file from TFS he needs to right-click on the file and "Delete" and "check-in". if he already deleted it locally he can do the "delete nonexistent files" and "check-in". now each developer when he does "Get latest" not will get the file.
You can also delete files with a tf.exe command line in the delete command:
tf delete [/lock:(none|checkin|checkout)] [/recursive] [/login:username,[password]] itemspec
During the build, you can add a command line/Power Shell task and run the tf.exe.
You can undo another person's changes from the commandline using:
tf vc undo /workspace:workspacename;owner $/project/path/to/file
You can get this information by calling:
tf vc status $/project/path/to/file /user:*
This allows you to remove pending changes from the server, though it won't cause the files to be reverted on the workstation of the developer in question.
Both commands offer a /recursive option to undo multiple files under a specific path at once.
If you're using Visual Studio 2015 or earlier, then you can use the TFS Power Tools to add a "Find by status" option to the Visual Studio Source Control Explorer. This has unfortunately not made it into Visual Studio 2017 and there are no TFS Power Tools for Visual Studio 2017.
The TFS Sidekicks offer a Status Sidekick screen, which allows you to query all files currently checked out for edit in server workspaces and allow you to undo them centrally.
Preventing the issue altogether
To prevent the issue altogether you have a few options. You can switch to Local workspaces, instead of server workspaces. Those auto-detect local changes and don't register changes on the TFS server itself. Read more about local workspaces.
You can perform the deletes from the tf vc command line instead of using other tools to delete files and folders, for example:
tf vc delete $/project/path/to/file
The delete command also has a /recursive option. Using this command will not only update your local folder, but will also update the server workspace.
how i can check in assembly info in tfs?
i am using tfs CI and i have one work space, when i try to check in pending :
2017-09-10T17:37:40.3410618Z No files checked in.
2017-09-10T17:37:40.8732772Z There are no pending changes matching the
specified items.
changes, tfs log show no pending change, but my dll version is right.
i can see assemblyinfo files in visual studio pending changes.
i am using assemblyinfo plugin in CI and i am check in with powershell command:
Tf.exe checkin $/[path]/assemblyinfo.cs
When you build in VS locally, the file assemblyinfo.cs generated within the workspace (the project in source control mapped) and will be detected automatically in Pending Changes page.
But according to your description, you build with TFS, that means the file assemblyinfo.cs is not in source control yet. Unless you publish/add the output to the active workspace just like build locally with VS, then you can check in directly. Otherwise you have to add the file to source control first, then check in.
So, just try to run "tf status" command first, it will show you list of pending changes.
tf stat /collection:http://server:8080/tfs/Collection
If that file not been listed, just run tf add first, then tf checkin (You need to change directory to your mapped folder first)
I would like to set the option File Time = Checkin on workspaces that are created with the tf.exe workspace command. In the Visual Studio 2013 Workspaces editor there is a field for this setting in the Advanced section and it defaults to Current Time.
The build server is creating workspaces with tf.exe and getting the code which then timestamps all the files to current time but I would like them to be time stamped with the last checkin time.
Is it possible to set this option on the command line so I that can include it in my build process?
BTW: If I get the timestamps to match last checkin I can speed up the copy process when deploying my websites by only copying the newer files. Currently it just copies everything even it is has not changed because the timestamps change on every build.
You can configure the file time setting with the filetime option. For example:
tf workspace MYWORKSPACE /filetime:checkin
Here is the simplified version of our gated check-in flow for a successful check-in:
Apply shelveset (build agent)
Build (build agent)
Revert Shelveset from Workspace (build agent)
Check in gated changes (CheckInGatedChanges activity on the controller)
Get the Changeset resulted from checking in the gated changes. (build agent)
This flow is very problematic. Indeed, suppose user A commits (submits to the gate) 100 source files affecting all the projects in the solution and then user B commits just 1 source file affecting just one project. How big would be the gated check-in build for the user B on the build agent?
The answer is that user B is going to "suffer" the same build as the user A.
The root cause: we undo the shelveset before checking in the gated changes and then get them again, this time in the form of a changeset. This bumps up the timestamps of the source files, making them newer then the binaries produced a moment ago from the same files.
That is a problem.
How do I solve it?
EDIT
Here what happens if I do not revert the shelveset, but get the respective changeset right away:
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 10/24/2014 10:36 AM 12 1.txt
PS D:\tfs\DFGatedCheckInTest2> tf get /version:C105656
D:\TFS\DFGatedCheckInTest2:
Conflict 1.txt - Unable to perform the get operation because you have a conflicting edit
Automatically resolved conflict: edit: D:\TFS\DFGatedCheckInTest2\1.txt as TakeTheirs
Undoing edit: 1.txt
PS D:\tfs\DFGatedCheckInTest2> dir 1.txt
Directory: D:\tfs\DFGatedCheckInTest2
Mode LastWriteTime Length Name
---- ------------- ------ ----
-ar-- 10/24/2014 11:42 AM 12 1.txt
PS D:\tfs\DFGatedCheckInTest2>
Notice the timestamp of the file. It was bumped up. We achieved nothing.
The reason why tf get /version:C12345 updates the time stamp is due to that being the default behavior for it in 2010. This was changed in 2012 and made configurable.
In Visual Studio 2012/TFS 2012 a feature was added that controls the file timestamp on get, read from Brian Harry's post from way back then:
Restore file modification time
When TFS gets files on to your local disk, it always sets the file modification time to the date/time that the get operation happened. There are some work practices where this is problematic. Some practices use the date stamp on the file for incremental deployment or other kinds of change management. SourceSafe had 3 options for setting the time stamp on files:
The time the file is gotten (this was the default and works very well in concert with make and other similar build dependency trackers).
The modification time that the file had when it was last edited before checkin.
The date/time that the file was checked in.
TFS 2010 and before only supported option #1. In TFS 11, we have added support for option #3. It can be set on a workspace by workspace basis. We plan to add support for #2 in the future but haven’t gotten there yet.
source
Back to the source of the issue
As you mention in your other question, you're using tf checkin /shelfset /force, which is where your problem lies. As the answer in your other question explains, that checkin goes directly against the server, the workspace on the server is unaffected and as such is left with the pending changes of unshelving that same shelfset.
tf checkin /force is also very dangerous in case anther developer had used by-pass gated build to check in changes. TFS will assume you know what you're doing and will overwrite these changes. So:
Developer 1 checks in filaA.txt
Build server starts gated checkin
Developer 2 checks in fileA.txt and bypasses gated checkin
Build server finishes and uses tf checkin /shelfset /force and thus overwrites the changes from developer 2
Instead, what the normal TFS workflow does, is check in the local changes on the workspace of the build agent. tf checkin $/ /recursive and it deletes the shelfset at the end of the build, in case of a succesful build and checkin.
This tells the build server to check-in the local changes in the workspace, and it will now know that it has the latest version, and won't have to update the time stamp. Next time the build is triggered the build agent will start with a get latest (to ensure that any bypass checkins are also fetched) and it will know these files are already up to date.
So in general your workflow, on the agent, should look like:
If workspace does not exist, create workspace and mappings
If there are any pending changes, undo them tf undo $/ /recursive
Perform tf get /recursive /version:T (get latest)
Unshelve your shelfset to the workspace of the agent
Build the code
Check in the local pending changes (tf checkin $/ /recursive), don't use /force
If all of that's succesful, delete the shelfset
If anything fails:
Undo all pending changes to reconcile the workspace
Leave the shelfset in tact
Fail the build.
That way the local workspace will better reflect what's going on and you won't have to perform a tf get /version:c12345 to mess up your dates.
I need help resolving the following issue:
I am attempting to unshelve code from the source branch onto a target branch.
I am using the following:
VS2012 RC
TFS 2012
VS2012 x64 Cross Tools Command Prompt
When I use the command prompt to perform the unshelve operation, the following occurs:
Shelveset details dialog gets displayed with list of change files.
Click Unshelve button.
Observe command prompt output: "An item with the same key has already been added."
I have downloaded ServicePack1 for power tools.
However, I have failed to resolve this issue.
I had the same issue and fixed it when I re-shelved the changeset from the source branch but chose not to preserve pending changes locally. After this the migration of the new shelveset ran smoothly.
(I also made sure I'd followed the below steps collected from other answers on this site)
Use a workspace that encompasses both source and target branches
Run the command from the folder mapped to the source branch
Check for quotes around any paths containing spaces
Deleting the cache in C:\Users[USERNAME]\AppData\Local\Microsoft\Team Foundation\4.0\Cache and restarting Visual Studio
I had the same error when using Visual Studio 2013 and the following command:
> tfpt unshelve /migrate /source:"$/Root/Solution" /target:"$/Root/Branches/Solution" "The name of my shelveset"
> An item with the same key has already been added
Research
Here's what I tried to fix the issue:
Clearing the Cache as per Andrey's answer
Try running the command from the Source -> Branch and Branch -> Source
My workspace already encompassed both source and target branches
Solution
Open up your equivalent of the VS2013 x86 Native Tools Command Prompt.
Check you have Team Foundation Power Tools installed:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\tfpt
Ensure you have 0 Pending and Excluded changes.
I had some Excluded changes which were detected but not added and this is what caught me out. Excluded changes should look like this:
Note: No "Detected: XX (adds)" - should not be visible
When you run tf status, you should see something like the following.
Either 1 change(s) for the .tfignore file or 0 change(s). Anything else will upset the merge.
C:\tfs\Root\Solution>tf status
File name Change Local path
$/Root .tfignore edit C:\tfs\Root\Solution.tfignore
1 change(s)
Ensure you are running the tfpt command from the source Solution directory
You should be now be able to successfully merge a shelveset from one branch to another.
Note on .tfsignore:
If you have a lot of pending changes that you don't want to undo for whatever reason, then
a modification to the .tfignore file is ok.
If this is the only file that you have left with changes, it won't brake the merge.
.tfignore reference => stackoverflow - How to ignore files/directories in tfs?
Try to undo all changes on Source and Target branch and then try again...
Try to delete all the files in the following folder and restart VS2012 (Source):
C:\Users[USERNAME]\AppData\Local\Microsoft\Team Foundation\4.0\Cache