I love the idea of check-in policies, but there are just some scenarios where you want to apply them on one project, but not another in the same solution. One obvious instance of this is with test projects. I'm all about some code analysis, but it makes no sense to waste the time applying or even scanning for code analysis violations. For this, I'd really like the ability to apply check-in policy exceptions to certain projects. This would make check-in policies much easier to deal with.
This is something like my request to go to the Source Control Explorer from the Solution Explorer in Visual Studio
; only this time, I want to go from the Source Control Explorer to the local directory I have a file checked out to. This would create perfect, seemless integration between the three file explorers. Of course, if the VS and TFS teams had any say in it, you'd never go to the Windows Explorer to get anything done. As nice of an idea as that is, it's just not feasible. Hell, I'm still looking for integration directly into the Windows Explorer shell. That'd be the best integration story, in my mind.
I can't stand the fact that a file's history only goes back as far as the last branch. When a file is branched, the history should include everything. I'm not sure why this wasn't the default action. As far as I know, this is how all (or at least most) other version control tools work.
One thing I find fairly aggravating is when I want to see files that have changed locally when I'm working with a TFS repository. Sure, I can see what's been checked out, but that doesn't mean those files have all been changed. Currently, all you can do is compare them one-by-one, which is a ridiculous process. Admittedly, my main reason for doing this is because I'm anal. I don't want files to be marked for check-in if they don't have any changes; specifically, I don't want them included in the check-in changeset. Based on this, I'd like to see TFS check-ins to ignore files that haven't changed or at least provide an option to do so.
Reported @ https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260449
Edit: Some brilliant, small-minded person closed the suggestion and said we should simply not check-in files that haven't changed. The problem with this is that means we have to manually go thru every file that's been marked as changed. Consider a large check-in that includes hundreds of files. Checking all those files would take way too long and nobody would do it. I'm somewhat aggravated about this. I'll probably end up reporting it again.
Edit: Looks like this might be in the Team Foundation Power Tool v1.2. The tfpt uu command says it is supposed to "undo unchanged files." The question is, what does this really mean? You can specify a changeset, which tells me it allows you to remove unchanged files from a previously checked-in changeset. If that's the case, I'm very excited about it. I just hope it undoes currently checked out files when a changeset is not specified. Once I play with it, I'll report back, but this really needs to get included into the product instead of being a command-line action that must be performed.
Team Foundation Server needs to have the ability to ignore files, like CVS (.cvsignore file) and Subversion (svn:ignore directory tag). The concept is simple. When checking in files, unnecessary files should be ignored. Visual Studio does a pretty good job at ignoring some files (i.e. bin and obj directories and .suo and .user files). There are times, however, that this isn't enough. For these cases, you need an ignore capability.
When checking in a file in VS against TFS, if you click on the Work Items section, select a work item, and change the Check-in Action dropdown by selecting it and pressing “a”, which signifies “Associate,” when you click off of the dropdown, the value is reverted back to the default, “Resolve.”
Reported @ https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=260453
Edit: I'm not sure who responded to this, but they obviously have a problem with English -- the first sentence didn't even make sense. They seemed to think the problem only happens on one work item as an odd occurrence. They suggested I discuss this in the forums. The problem with that is that I've been able to reproduce this on all work items using multiple TFS instances.
I really want the ability to revert files from the check-in screen in Visual Studio. I use this a lot more than deleting files
. Basically, Visual Studio needs to mimic TortoiseSVN
Visual Studio needs to allow users to delete files from the check-in screen. The capability is pretty simple, but very useful.
I love the fact that I can create private and shared queries. Apparently, so does everyone else. I've seen the number of shared queries grow and grow over the past few weeks. Granted, I think this is in part because people get a new toy and they want to see what it does, so they go hog-wild with it; but at the same time, the shared queries are very useful. Most of the time, tho, they're only useful for certain groups. For instance, I don't care about the 5 different reports the QA team wants to run. So, why should I have to look at them all when I am in the shared queries folder? I shouldn't. The way I get around this is by creating shortcuts to the queries I use; but that doesn't resolve the clutter issue. There needs to be a way to add some organization here. Having the ability to add folders would resolve that immediately. I'm not sure whether a better solution exists, but I'd be open to anything.
Edit: This has already been reported three times (1 , 2 , 3 ). Looks like it will be included in a future release, probably the next release.
One thing I hate about the great and wonderful integration between Visual Studio and Team Foundation is, when I perform some source control action (i.e. get latest), I lose all control of the app. This means I have to wait who knows how long until I can do other TFS tasks, like looking at the open work items. Work items have nothing to do with my check-in status -- well, I can see how an items status might be updated during a check-in, but you'll always have concurrency issues like that, no matter what you do. I would love to see source control actions not lock up the environment; especially if the environment is going to be central to all project actions.
Perhaps this wouldn't be an issue if there was some information on who has a file checked out easily accessible, but until then, I want to have the ability to browse directly to a file in the Source Control Explorer. I'm thinking of an item on the context menu of the file in question from the Solution Explorer. This should work fine.
When a project in Visual Studio is tied to source control and a file is checked out, there's a user icon on the file. This is nice, but when you hover over the item, the tooltip says, "Checked out by someone else or in another place." Gee, that's not very useful. What if I want to know who has it checked out? The only answer I know of is to find the file in the source control viewer, which can be tedious at times. Having this info in a tooltip would be nice. Better yet, bring me to the user's profile or something.