MS Team Foundation Server 2015, with the native TFS SCM:
On the main branch, every user can see pending changes from every other user.
I branched off a branch from the main branch with several check-ins in the past already. I'm currently having locally modified files on that branch and see them as pending changes in Source Control Explorer. However another colleague does not see these pending changes. Why?
(He can see pending changes on the main trunk just fine like everyone else.)
Is it a property of the branch that i need to set somewhere?
You need to check whether you have mapped the Main and Branch in the same workspace. And check whether you are using server workspace.
Related
I created a branch in TFS off of the main branch. Then in this new branch I made a few changes and added a few files. I checked in my changes. Afterwards, I merged this branch back to the main branch.
Then I opened the main branch in Visual Studio and did a get latest version. I expected to see the changes I made in the branch. But they are not there. If I look at the main branch in Source Control Explorer, I see the files that I added.
How do I get my merged changes to show up?
Turns out that when I did the check in, the files that were new got checked in. But the files that were changed didn't (and I somehow lost their changes). These new files made it back to the main branch. So I went back into my branch, and made the changes to the files again. Then I checked them in. Next I merged again. This time everything worked and my changes were in the main branch.
When my team and I were on visual studio 2013, after successfully checking in our pending changes, the files that were checked in would be removed from the pending changes window.
Ever since upgrading to 2015, we have lost this functionallity. Now, after a successfuly check in, the pending changes will remain in the pending changes window until they are manually undone or and identical check in is undertaken in which case all of the files will sync themselves with source control and will no longer be pending changes.
When diffing the files with their counterparts in source control after a successful check in, it is clear that there are no changes between the two despite the fact they are still in the pending changes window. Is it possible that we have overlooked a simple setting that allows us to sync with TFS immediatelyafter a check in?
Thanks
Never seen your issue before. Try to upgrade your TFS and VS to the latest edition.
Also, if the pending changes are under Excluded Changes, they won't be checked in.
https://www.visualstudio.com/en-us/docs/tfvc/develop-code-manage-pending-changes#work-with-automatically-detected-changes
https://www.visualstudio.com/en-us/docs/tfvc/check-your-work-team-codebase#include_exclude
Does TFS support local commits?
In other words: Can I
modify the code,
make a local commit (without sharing these changes with others),
test my modifications and
if my changes didn't break anything, do a global commit (thereafter my changes are available to other developers)
in TFS 2012?
If it doesn't, are there any workarounds, which allow this functionality?
No it doesn't support this, however it does have a couple of alternatives you can use instead.
1) Branches - All developers work on their own branch then merge to trunk/main when they're happy with their changes.
2) Shelveset - developers shelve any change they don't want to commit yet. This lets you undo your change, or pass it to another developer on the team without losing the change or checking into the main branch
3) Gated Checkins + Unit/Automated tests. Any time a developer checks in, TFS Automatically shelves the changes and runs the tfs build + any associated tests (unit or automated). If everything succeeds then it is checked in. I don't believe this supports manual tests.
or a mix of all of the above.
TFS does not support this by itself.
However! Microsoft released Git integration with TFS. Brian Harry blogged about this: Announcing Git Integration with TFS a couple of weeks ago.
Using this setup you can use Git for your local commits and then commit it to Team Foundation Server.
Not for the on premise version of TFS (yet), but as of January 2013 Microsoft's hosted Team Foundation Service has Git support, which obviously supports local commits.
http://tfs.visualstudio.com/en-us/news/2013-jan-30.aspx#git%20support
I have checked out from the main trunk and made some changes that I do not want to go back into the main trunk. If I create a branch in TFS after I have already checked out the code, how do I check my code into the new branch that did not exist when I originally checked out the code?
You need to shelve your changes and then unshelve it into another branch
I'm a consultant whose client runs a TFS 2005 repository. I manage my own source code in TFS and deliver my releases to their TFS. My source code is around 20,000 files that I maintain.
My normal process:
Detach my solution from my TFS
Connect to their TFS
Checkout the entire project
Overwrite my project files with
theirs
Check everything back in
Click the add button and add any new
files that have been added
Check everything in
Open the solution file and bind it
to TFS
Check everything back in
The main problem I'm seeing with this approach is if I delete a file on my end, I don't have a way to reflect that change.
I'm also not interested in synchronizing tools because I don't want to synch every checkin, just the current state.
Is there a way I can do this better?
What about maintaining parallel .sln and .proj files with the different bindings? Do they change often?
I think you can maintain change history by using the TFPT ONLINE command from the Team Foundation Power Tools.
Open SLN_A
Make changes (VS auto-checks out against TFS_A)
Before checkin on TFS_A, run TFPT ONLINE against TFS_B. This should pick up adds, edits, deletes.
Checkin SLN_A on TFS_A.
Checkin SLN_B on TFS_B.
Only problem with this might be that the SLN_A checkin could screw up the SLN_B pending changes b/c the files will be returned to read-only. Not sure.
Why do you need to maintain a parallel TFS? Seems like you ought to be working directly against their TFS, either on a branch, via the Proxy, or both.
Have you looked at TimelyMigration? (No affiliation and I've never had need to use it)
TFS to TFS migration