The company I work for recently started using TFS 2010 for version control and we have had some active discussions on establishing a check-out policy. Currently, we have Multiple Check-Outs enabled. This policy is enabled because, as a small dev team, we can always get together to discuss merge conflicts when they arise at check-in time. One thing we didn't reach a consensus on was getting the latest on check-out. Should we also enforce the "Enable get latest on check-out" policy? Does it go a long way in helping to ensure that we aren't editing out-of-date code?
It is better to leave it disabled because each user can enable this option locally in Visual Studio according to their preferred way of working by modifying their settings in Visual Studio (Tools Menu -> Options -> Source Control -> Visual Studio Team Foundation Server).
Most of the teams that enable this option are coming from a system that already behaved this way (Visual Source Safe, mostly) because they are comfortable working that way already.
I find most people want to explicitly control when their files are getting updated so others' changes don't unexpectedly mess up their flow when they might not be ready for the latest changes their team members had checked in ahead of them.
However, every team working with shared checkouts on an active project should be trained and aware that it is good practice to get the latest changes regularly, as it will reduce the amount of conflicts and confusion when they finally want to check in their work.
Consider getting the latest version of the code:
When you start working for the day.
Throughout the day if it is a really busy project
Most importantly, right before you check in your changes you should get the latest changes and then test your build.
Related
How do I view and integrate with GitHub issues using Visual Studio 2022?
When connected to an Azure Repo, the VS Team Explorer window includes a "Work Items" view that shows open issues from Azure Boards. I can easily create a branch from one, link it automatically, and submit pull requests. The integration is great.
When I connect to a GitHub repository, that integration is lost. The Team Explorer window no longer contains a "Work Items" view. Since I can't view the issues, I can no longer automatically create branches that are linked to the issue. I have to now manually type in the issue number if I want to link a commit to the issue. And the "Create Pull Request" menu items simply launches the browser to the GitHub page; there's no integration there, either.
I have found a VS Code blog post that enables a lot of this functionality (and more) into VS Code, but I've yet to find anything for Visual Studio 2022. From that post, I am most interested in the "Working on issues" bit. As described above, this was functionality that worked with Azure Repos but is lost with GitHub integration. How might I regain that functionality with GitHub and Visual Studio 2022?
The "old" team explorer did a number of really nice things, but it was also very hard to integrate into for other tool vendors. With the new Git experience the Visual Studio team opted for a more agnostic approach.
The old Team Explorer was written in .NET 4 and was very much geared towards integrating with Azure DevOps. It stems from 2005 when Team Foundation Server first got released. Over time other vendors snuck their way into Team Explorer, but mostly through undocumented and unsupported ways. This has caused many interesting issues in the past. The concept of the Team Explorer window also wasn't ideal for hosting GitHub, Azure DevOps, BitBucket and every other tool-vendor that wanted to be listed and there was very little in the way of control for users to set the order of elements or hide certain tiles. As such it's a breeding ground for bugs and it needed to be ported to .NET Core and x64 and to support out-of-process extensibility to properly support Visual Studio 2022 anyway.
So Team Explorer and its old undocumented extensibility points were dropped and the new Git Window was born. This window is a pure git client and it's vendor agnostic. Vendors may add menu items to the top level menu, but they currently can't extend the new git window.
At the same time, Visual Studio 2022 dropped support for the built-in browser window, which was a memory hog, loads IE11 and also needed full retooling to support the x64 out-of-process loading that Visual Studio 2022 now demands.
All of this work now allows Visual Studio to use more memory, it's faster and by moving extensions out-of-process, it has greatly improved the performance and stability of the visual studio platform. Unfortunately this all happened at the expense of some features.
The new git experience is no longer constrained by the Team Explorer window, is a top-level citizen in Visual Studio and can finally use easier to remember keyboard shortcut keys. It's much faster too and the new architecture allowed the team to build interactive rebase, multi-repo support, submodule support and more. But their priorities have been in advanced git scenarios for a long while, not in building support for vendor specific issue integration. It looks like that may be changing though. Auto-completion of #... is now in Visual Studio 17.5 preview:
Some tool vendors may invest in native integration into Visual Studio in the future. Many old extensions are no longer available in VS2022 or the authors are still working on a new version that conforms to the new requirements.
On the other hand you have VS Code, which is used by GitHub itself internally, runs in a browser, powers github.dev and github codespaces and doesn't carry the legacy if Visual Studio 2022. It's not Microsoft, but GitHub who has extended vscode and they added the support for their platform through extensions and open source contribution to the editor directly. GitHub has a different stake in vscode, they have the engineering staff that knows how to extend atom-based applications (they basically built that technology) thus, their features have been added to vscode.
Is it fair? Do we want it in big VS as well? Sure, but unfortunately, that's currently not where the money is being spent.
There are a few ways to accomplish what you want. But none are exactly what you desire.
The web
The main way is to start working from the browser. On every issue there is a Development section from which you can create a branch or initiate a pull request from the associated branch:
You can then immediately check it out locally
Or navigate to the code panel for the branch and click the open in visual studio link. This will launch visual studio in the correct context using the repo you selected and will check out the branch locally for you to start working.
Any commits you make to this branch are automatically associated to the issue, so there's no need to pass in the #issuenumber every time.
The cli
An alternative to working from the browser is to use the CLI. If you have the GitHub CLI installed it will pick up the context of your repo from the list of remotes and you can perform quick commands straight from visual studio's built-in terminal.
gh pr create
to create a new PR.
gh issue list
to quickly list your open issues
gh issue develop #issuenumber
to create a branch on the remote, associate it to your issue and check out the branch locally.
It takes a bit of getting used to the commands, but if you like the CLI it's a quick way to work.
In Visual Studio
You can create pull requests from your current state, which will then bring you to the browser with most of the data pre-filled. Issue auto-completion also works in the browser from that point forward.
To get the other features you want, you must install extensions. Unfortunately, GitHub has stopped development on the old GitHub for Visual Studio extension since most of its features have now moved into visual studio. It's not easy to build and maintain an extension for multiple versions of Visual Studio, so I don't expect this will be brought back to life.
I rely on the Git Web links extension to quickly switch between web and visual studio from the context of my working files:
In the settings you can set the default behavior to not copy, but to open in browser.
Other functionality you're after is currently not available through a publicly listed extension. Most of there features have also been removed or deprecated for Azure DevOps itself, so I don't expect the Visual Studio team to be in a hurry to add first-class support for Issue tracking back in.
Unfortunately, the "Work Items" view and the related issue integration for GitHub Repos is not currently available in Visual Studio 2022 out of the box.
You might be able to find a Visual Studio extension that provides this functionality, but I'm not aware of any off the top of my head.
An alternative option would be to use the GitHub API to retrieve the issues, and create a custom extension to display the issues in Visual Studio 2022. However, this would require custom development work on your part.
It seems like the VS2022 will have this feature in future (it's in Preview now).
https://youtu.be/0NiHvdoMBO8?t=95 [VS2022 Preview Feature]
We use Team Foundation Server (now Azure DevOps) in conjunction with Visual Studio as our version control system.
I am our teams ssrs report developer and, unfortunately, sometimes throughout the course of my day I'll be working on multiple projects and will have a report checked out, however I'm unsure what changes I might have pending (it could be something actually valuable for production, or just something I was testing). Is there a built in way to compare pending changes to the code vs the current saved version?
Per Daniel Mann's excellent comment, the answer is very simple. Right click > Compare!
I understand that TFS Local Workspaces are designed to help users work more seamlessly when not connected to the TFS server; however, unlike when using Server Workspaces, I cannot see the status of a file from Visual Studio Source Control Explorer. Our team is connected to the TFS Server 90% of the time. It seems that Local Workspaces should be able to communicate file checked-out status back to the TFS Server when connected. As a team manager I would like to know what files team members currently have checked out in several scenarios, while still retaining the flexibility offered by Local Workspaces.
I want to know how often team members are checking in their code (or not).
I want to know if someone is already working on a file before checking it out as well.
I want to handle a lost/broken laptop scenario by knowing which files had un-checked-in changes.
Is there a way to do this with Visual Studio Source Control Explorer or another tool?
Generally the items checked out will display automatically when you navigate to the specific items in Source Control Explorer. Reference below screenshot.
I want to know how often team members are checking in their code (or
not).
You just need to check the changesets history.
I want to know if someone is already working on a file before checking it out as well.
Just navigate to the specific items in Source Control Explorer as I mentioned above, it will shown the status in Pending Change column.
I want to handle a lost/broken laptop scenario by knowing which files had un-checked-in changes.
Generally the files with status displayed under Pending Change column are the files which have un-checked-in changes.
However there is a tool called Team Foundation Sidekicks which is a suite of tools ( includes Code Review Sidekick, Shelveset Sidekick, Labels Sidekick, History Sidekick, Workspace Sidekick and Status) for TFS administrators and advanced users providing rich GUI for administrative and advanced version control tasks, you can use it to check and track the things you required. (Unfortunately it's no available for VS 2017, the latest version 6.0 only works for VS 2015)
How to customise I have knowledge to customise process template in tfs 2015 or in 2012 but for upgrade version in 2017 is there any changes or any enhancement.
I have find in google but I have not found any helpful to customise process template in 2017 specifically.
your help should be appreciated. thanks
The first step is you need to download the process template you want to edit from you TFS server. To do this, launch Visual Studio and navigate in the menus to "Team -> Team Project Collection Settings -> Process Template Manager". When the dialog shows up, you will be able to select the template you wish to edit and download it. Detailed instructions for this can also be found here.
Once you have downloaded the process template, you have a series of XML files that describe how TFS should handle almost everything when you create a new project using that template. The XML can get overwhelming quickly, even for the most seasoned person. You should ideally use the Process Template Editor which is a plugin for Visual Studio (the link is for Visual Studio 2017). For details on customizing a template, you should start off by reading the Customize a process template on the Visual Studio documentation site.
Once you've made your changes, you simply need to upload your process template back to the server using the Process Template Manager (where you downloaded the template). If you replace an existing template, anything using that template will get the updates. If you create a new template, only new projects using that template will be able to make use of it.
Not much has changed with editing the process templates between TFS 2013, TFS 2015 and TFS 2017. So if you find a blog or a write up on one of the versions, there is a good chance it's still valid. There may be slight differences in UI, but there shouldn't be anything ground breaking.
DISCLAIMER!!!
Now that I've answered your question, I would be negligent if I didn't explain the dangers of what you are about to do. Customizing a TFS process template can be very dangerous to your TFS server. Microsoft does not guarantee or put any warranty on changes you make. You customize a template, you are on your own. You have to understand that this template literally tells TFS how to work. It is highly recommended to have a sandbox environment complete separated from your production server and make all changes in said sandbox environment first. Only after you've validated the changes should you move it to your production environment. In addition, anytime you deploy a change to your production server, make sure you have healthy backups your databases. I can't stress this enough.
Lastly, any changes you make, you run the risk of locking yourself into a specific version of TFS or making your upgrade path far more difficult. My last piece of advice is to carefully weigh the need for customization over the risk associated with making it.
I have some projects to work on that involve a grotesquely large csproj that is the COTS CMS application I'm extending. The project has over 16k files in it which is ridiculous but it's not something I can control, nor can I control the choice of CMS platforms. The project is in a solution... the solution is in a git repository.
With a project that large, using the source control plugin in Visual Studio 2013 means any change to a file and subsequent save results in my CPU and RAM usage spiking to a ridiculous percentage for several minutes, making the fan spin on high constantly all day and making my IDE laggy. I have a very high-end desktop replacement laptop and I'm certain throwing hardware at the problem won't make it go away. So, I go into options and set the source control provider to None... problem solved after a couple-minute lockup while VS does something.
Now for the problem... when I come in the next day and open up the solution, the plugin selection is back on Microsoft Git Provider. Is there a setting or something I can configure to tell Visual Studio (ideally for just this solution or project) to stop trying to use the integrated source control?
I had the same problem, I need the Work Items from TFS but I use git-tfs to manage my projects locally.
I managed to disable the built-in Visual Studio Git Provider by deleting all occurrences of those registry keys:
7FE30A77-37F9-4CF2-83DD-96B207028E1B
11b8e6d7-c08b-4385-b321-321078cdd1f8