I have two VS2013 sessions opened, each with a solution that is version controlled by the same visualstudio.com TFS repository.
In one project I wanted to check in some files, but Check In will always want to check in changed files from all my other VS projects.
Is there a way to make Check In work only on the current project?
It's very confusing when checking in project A also checks in project B when I am not ready or certain about the state of project B.
Check ins are based on your workspace, not the solution or project you are working on, which means a check in will always detect changes made in any of the folders that have been mapped from source control, regardless of which instance of Visual Studio they were made in (since it looks at the physical disk to determine what changed).
You can be more specific about your workspace mappings and/or use multiple workspaces if you wish to have a smaller scope for your check ins, though this brings with it usability complexity as you now need to ensure source control explorer and pending changes are referring to the correct workspace.
If instead of checking in with no scope (defaults to workspace wide) you can right click on the scope you want.
If you right click on the solution and select check in, Visual Studio will filter the checkin for you. It will be scoped to only files in that solution.
Whenever this happens to me, if I have made changes in the VS instance i do not want to check in, then navigate back to the one i want to check in, I am presented with an alert box that says something like "the files have changed, would you like to update them?" If this is true for you, you could just say no.
Alternatively, if the each VS instance is touching code in different branches, then you may choose to "exclude" (in team explorer) these other-branchly files.
Related
I am using Visual Studio 2107.
Looking at the “Pending Changes” panel in Team Explorer, there are two list for “Included Changes” and “Excluded Changes”.
I can use the Filters option to display only files that match a certain pattern. However, I want to be able to hide files that match a certain pattern.
The reason is that I have a number of files regenerated during the development process; these files all have the same name in different projects. They clutter up the list when I am reviewing what to check-in.
Note that I don’t want to exclude these files from being checked-in; they will be checked-in to source control eventually. I just want to be able to review the Changes list without these files displayed until I want to see them.
It seems straightforward but I can’t seem to figure out how to do it. And I can’t seem to find the right phrasing for Google.
How do I hide files in Team Explorer Pending Changes View?
If you don’t want to exclude these files from being checked-in, I am afraid you could not hide files in Team Explorer Pending Changes View.
According to the document Develop code and manage pending changes:
Almost every change that you make to the files on your dev machine is
stored in your workspace as a pending change until you check it in.
If items that you don't need to check in appear regularly in the
Promote Candidate Changes dialog box, you can select one of them, open
its context menu, and choose Ignore this local item to ignore the
item. You can also choose Ignore by extension or Ignore by file name
to create a file that will cause Visual Studio to systematically
ignore this kind of file.
So, Pending changes will detect all your changed files unless you don't want to check them in.
So, to hide files in Team Explorer Pending Changes View, we need to use .tfignore file to ignored files to folders that are mapped in a local workspace, they do not appear in the Pending Changes page in Team Explorer. When you want to check them into source control, you can move them out from .tfignore file.
Hope this helps.
Hiding files from Pending Changes is not supported without fully ignoring them.
I'm making an angular webapp for a C# solution and I have to use TFS.
I set my workspace as local (as described here) and added the angular folder from Source Control Explorer.
Now all existing files are marked with the [add] tag and I can check-in them, but I can't understand why added or removed files are not detected as pending changes.
What am I missing?
They're under "Excluded" changes. You'll see a marker that says "Detected: X adds" or "Y removes". You can click it to promote them to tracked changes. It assumes that stuff that's being added or removed outside of Visual Studio isn't intended to be in source control, so it doesn't start tracking until you tell it that you want them to be tracked.
This may not be the perfect solution you're looking for, but I ran into an almost identical issue. This is how I solved it,
1) Open Solution Explorer in Visual Studio
2) Find your Project ( Angular Project )
3) Right click on it, and click Compare changes.
4) In compare options see View Options and check the following:
Show items that exist only in source path
Show items that exist only in target path
Show items that are different
5) Then find all the files that are in your local mapping that are missing from your server version, right click on them and click "Add file". You should be able to do this for entire folders / groups of files using shift + click .
6) Once you've added all your missing files, make sure they're being tracked in Team Explorer -> Pending changes, then check in your files.
I haven't figured out how to get Visual Studio to track these files automatically as I believe it requires a solution file like in normal C# projects to track them, but I could be wrong.
When I check in changes in TFS Express 2013 using Visual Studio 2013 Professional, there is a list of "Excluded Changes" that has 1541 items in it.
I have never told TFS to exclude a change, and do not understand why anyone would even want to "exclude" a change (isn't source control all about SAVING changes???). I am a bit worried that I have changes that are not being saved...but am even unsure if this is even what it means. I have Googled for more information about "Excluded Changes" in TFS, but haven't found any explanation.
Can anyone explain to me: What are Excluded Changes? Why would I want to exclude a change? And why are there 1541 excluded changes that I never requested to be excluded? Should I be worried that changes are being excluded? Should I change these excluded changes to INCLUDED changes?
There are a number of things that can cause a "change" to be excluded:
Team Explorer will, by default, ignore files in obj/* and bin/* and a few other folders. As well as certain extensions like .csproj.user.
They're not loaded in your current solution, so Team Explorer assumes they're made as part of either a different solution and that you don't want to check them in together with the changes that do match the context you're in.
They're made in a different workspace, again Team explorer assumes you want to check in groups of files that logically make sense.
They're manually excluded from the current checkin. You may do that when you want to first check in one file that fixed Bug 123, then check in another set of files that fixed Bug 124.
Files created outside of Visual Studio are never automatically added, so when you zip up a set of .cs files and that zip ends up in your workspace folder, Team Explorer will detect it, but won't add it automatically.
There is a final issue that may be going on here, if for some reason a project hasn't been added to source control, or the bindings in the solution file were not checked in correctly, then any file added to that project will be ignored as well, as Visual Studio assumes that project should not be under sourcecontrol.
Using "Add existing project" doesn't automatically put that project under the same source control bindings as the solution. which would cause team explorer to assume 6.
The path may previously have been "cloaked" or "unmapped", mapping a folder after the fact doesn't tell Team Explorer to add them.
You may have been working offline and were using a server workspace. When you tell Team Explorer to come back online, you need to ensure that all adds are correctly done. A Local workspace doesn't have this issue, as it can locally track the changes without having to talk to the server.
You may have chosen "Check in pending changes" from a subfolder in the Solution Explorer (or on an individual item or project) or in the Source Control Explorer. When you do that, Team Explorer scopes the Pending Changes window to only the items that match that context. All other changes are temporarily moved to the "Excluded Changes" section.
You should inspect the Excluded Changes list and either ignore them using your .tfignore file. You can do this from the UI as well by right-clicking such an excluded change and choosing the option to ignore by path/extension or pattern.
Basically, if you see stuff in the Excluded Files section, either right-click/include them or add them to your .tfignore file.
That way it's at least very clear that items in that list have not been evaluated yet and most probably need to be included.
You may also want to check your source control bindings by opening File/Source Control/Advanced/Change Source Control Bindings... to ensure that all projects show as bound to sourcecontrol and don't show any errors.
Some additional context
In Git as well as in other source control systems, changes are often not automatically pended. This is to prevent you from accidentally checking in stuff that you did not intend to. In Git you need to explicitly call git add to mark a change as one that you intend to commit. Until you do that the change is considered "untracked", which is essentially the "Excluded Changes" feature of TFVC.
Subversion (SVN) has a similar behavior where changed files are marked as unversioned and need to be added explicitly through calling svn add.
So this isn't very strange behavior for a source control system. It essentially puts you in control of your sources.
Wanted to give another case where files are excluded. If you add a project from template or a new item to your project that includes a default name like "MainWindow" then rename or delete that file before ever commiting changes. "MainWindow" will be in the excluded changes and the item with new name will be in Included changes. In this case you can safely delete them.
I have a very strange situation.... After migrating from StarTeam to TFS (using TimlyMigration == awesome) there is one oddity.
When I look at any given file in the Source Control view, I see all the history that was migrated. However if anybody else on the project looks at the file, the don't see the history. it sounds like a permissions issue, but even if I change their group membership adding them to project administrators they still don't get the history.
So I'm wondering if there is perhaps a problem with the resposity, and if there is an internal consistency checker for TFS that I could be running.
Does the history include any renames/moves? TFS permissions are based on paths, so if people don't have rights to the "old" path then they won't see the history entries before the move.
One other thing to look into is the permissions in the source control (assuming you have given permissions to the project).
In the Source Control Explorer right click on the project and select properties. Then select the security tab. Users should not need to be added to this, but I have had to do it in some cases.
Vaccano
I am working on a Visual Studio 2008 project that is already added to TFS server.
I am not sure which settings and policies have been configured for the TFS (this is done by a separate dept, not developers)
Every time I make an edit to a code file , the file is checked out automatically (without explicitly checking out the code file myself)
Please help me locate this setting or policy because it is not very useful at the moment. Sometime you want to make a local change to try out something, and not necessarily check out the code....
It is in Options\SourceControl\Environment
Checked out Items: Check out automatically
change it to
Checked out Items: Prompt for exclusive checkouts
or your preferred action.
Unfortunately, with TFS it puts read-only locks on your files to PREVENT you from editing the file without checking it out first.
I cannot stand this decision. What you'll have to do is allow TFS to check out the file, then "Undo checkout" on it later if you don't want to check it out.
Make sure you have shared checkout enabled, exclusively locking files is the path to madness. ;)
I think this is a feature not a problem. If you change a module and it's under source control, you are now "out of sync" with the repository. If you exit (and the default behavior is to save) - and come back later - the file is not what everyone else is seeing. This can be dangerous.
For example: back in the days of VSS - on a Friday afternoon I had to "put out a fire" and debug a problem in, Prod Environment, so I changed the connection string in the appropriate config file. Another developer had the file checked out - so I did the usual workaround to mark the file read-only so I could save it. I figured out the problem and informed the user. This was in fire-fighting mode - so I didn't consider the fact that I now have production connection string in my dev configuration.
Monday mornign I come in and open up the solution. Is there any feedback telling me the config file is pointing to production? No I have to remember.
If the file is checked-out however - that icon is indicator to me that "flags" the fact that the files have been modified. I don't quite understand the "big deal" in having to right-click the solution and say "un-do pending changes"
Or if you want to save them, as the down-voted suggestion by aleichtle.wordpress (I don't understand the down votes - I think it is an excellent suggestion) explains, you can shelve the changes. This will remove the check-out and also save the changes on the server.
Version Control systems are a critical and important component of the software development life cycle. It is important to consider your "process". You may need to make adjustments as you use a different tool ("When in Rome"....)
It may be difficult to make the adjustment - but there are often good reasons the tool works the way it does.
You can make a shelveset of the code allowing you to make a change to the code without affecting the rest of the development.
You can do this by right clicking on the file and selecting shelve pending changes.
I'm running Windows 7 and VS 2010.
From Windows Explorer, you can
- right-click on your project's main folder
- Choose Team Foundation Server
- Choose Workspace
- Remove the active Working Folder (bottom of the screen).
I belive this removes the bindings to TFS, and you're free to wreak havoc on your code at will.
Close your solution.
Unplug your network cable.
Open your solution.
Visual Studio will tell you that TFS is not available and will open the solution "Offline".
Plug your network cable back in. VS should not take the solution "Online" until you explicitly ask it to.
You can then make any changes you like. When you attempt to save files it will tell you they are readonly - just overwrite them.
If you decide you want to check them in, take the solution Online by right-clicking it in the Solution Explorer.
Otherwise, just delete the local copy of the source when you're through with it.
You can remove binding to source control from file menu.