7 votes2 comments · Visual Studio Team Services » Dashboards and Reporting · Flag idea as inappropriate… · Admin →
2 votes0 comments · Visual Studio Team Services » Version Control (Git/TFVC) · Flag idea as inappropriate… · Admin →
39 votes6 comments · Visual Studio Team Services » Version Control (Git/TFVC) · Flag idea as inappropriate… · Admin →
While reviewing a pull request, particularly a large one, I’ll often review many commits individually so I can see the explanatory commit messages and gain a quicker grasp of the changes within the PR.
When I’m reading the commit diff and I see something to comment on, I usually click the ‘add comment’ icon to add the comment inline with the code. The problem is, since I’m on a commit diff rather than a whole-PR diff (or a PR update diff), the comment is never seen. It doesn’t show up in the discussion under the Overview tab, nor does it get emailed as a PR comment. This keeps catching us out at work.
(Occasionally, viewing and commenting on a PR update diff is a workaround. This only works when exactly one commit has been pushed to the open PR at a time. This is rare.)
I'm used to this just working with GitHub PR commits. GitHub knows whether you’re commenting on a PR commit or a non-PR commit, and it adds the comment to the PR discussion as appropriate. ‘Just working’ in TFS would be my favorite outcome, though second best would be to remove the commit comment feature so that I am not misled into commenting there so frequently.
301 votes17 comments · Visual Studio Team Services » Administration & Licensing · Flag idea as inappropriate… · Admin →
This is critical because of the ultimatum that switching to VSTS becomes. We need to know there is a way out back to on-prem, even if we never use it.
Git repository backups are much less important than project setup, work items, builds and anything else needed to continue if, say, we switched back to on-prem.
44 votes2 comments · Visual Studio Team Services » Version Control (Git/TFVC) · Flag idea as inappropriate… · Admin →
They have added this in Visual Studio 2017 Update 6 Preview 2! 🎉
Apparently the search terms become the title, and there is no way to edit the title once posted. Apologies for the lowercase.Joseph N. Musser II shared this idea ·
For one thing, I don't think it really is an infestation. I've been in a good variety of codebases that use it and it has rarely been laborious. But I know what you're referring to, so let's just go with that. How would you remove it? You would have to go either 100% sync or 100% async or invent a way that the same code could run both ways. You can't run synchronous methods asynchronously without losing all benefits of async and you can't run asynchronous methods synchronously without losing all benefits of sync.
Each scenario is specialized. Say you're reading from I/O. If the code runs synchronously, you make the system call to read. If it runs asynchronously, you make a system call to be notified when the system is done reading and then call back to a thread pool thread or to a UI message pump. Those two are nothing like each other but each has distinct benefits that we need to keep around. You have to keep two distinct methods around for this because sometimes you need one and sometimes the other. Does that make sense?
Async is inherently expensive just because it's the ideal solution to an inherently expensive problem. You want to make it very clear when you are and aren't using it. Moving to a world where it's all the same method and same return type for extremely different processes would be frustrating.
I'm not really sure this is actionable or even desirable. The "zombie" infection and having *Async versions of methods and async void are actually the *ideal* outcome as far as I can tell. There is no helpful way to generalize async and non-async code that I have been able to find. Without async void, how would you be able to write async event handlers in any practical way? I could go on.
Unless you have some ground-breaking theory proposals to point to, it sounds like you're mostly complaining about the fundamental nature of async programming rather than complaining about C#'s solution in particular. C#'s async/await is quite the state of the art right now when it comes to solving the callback **** problem, so perfectly executed that other languages are copying it.
On the cutting edge there are exciting improvements like custom builders for custom Task-like types, but for the most part the dichotomy between synchronous and asynchronous (callback-driven) code is a practical and useful one. Certainly, I may stand corrected on this and that would be exciting, but we'll need to be pointed to some heavy-duty research rather than complaints. No offense!