This is an option to enable/disable on a per project basis.
The diff tool can be used to compare between revisions when showing the history of a file. The diff tool will highlight portions of code that differ, even if it’s a single line of code. The internal deltas stored in the repository are not directly accessible. Furthermore, check-ins generate churn data in the reporting database to indicate how many lines were modified, deleted and added.
Unlike many past source control plug-ins for Visual Studio, when you rename, move, or delete a source-controlled item, you do not have to worry that your change will not be properly shared with your teammates. The change is isolated in your local workspace as a pending change until you check it in. When you do so, the change is propagated to other users' workspaces the next time they perform a Get or Check In operation. This is particular type of file change (similar to an add or an edit). From the command line you can specifically use the rename or its move alias to rename/move a file or an entire folder. This is automatically done inside the IDE in relation to a rename/move of a file.
Somewhat. There is a hierarchical view, but not really on a file by file history basis.
More traditional branching models are supported by TFS which are not directly comparable to Shared Projects with pinned files. The Team Foundation Server approach is more robust and scalable than VSS.
Yes the built-in merge/diff tool provided supports comparing all the primary text based file types commonly used in Visual Studio (i.e. .cs, .csproj, .vb, etc.) Any file type can be associated with either the built-in tool or any external merge/diff tool.
TFS supports both manual and automatic merge resolution through its diff/merge tool/engine. Most of the native “source” file types a supported (i.e. .vb, .cs). You can associate any file type to Team Foundation Server and specify which ones can be merged (typically non-binary file types). You also have the option of associating 3rd party merge/diff tools to support other file types (i.e. MS Word, etc.)
There are two options here. For individual work in process, work transfer, or work interruption, files can be checked-in to a ShelveSet which does not affect the primary branch. The other option is to create multiple branches to segregate development (i.e. DEV, QA, PROD) and then promote/merge ChangeSets from one branch to another.
Yes. Multiple files checked-in at the same time are atomically committed to a SQL Server 2005 database and a referencable artifact known as a ChangeSet is published. This can be used at a later point in time to view the contents of a check-in, associate to work item or build. It can also be used the same way a label would be used “Get me all the source code as of ChangeSet 155” which would include the image of the entire source branch (not just the changed files) as of that moment.