I would like to evaluate the performance of a new developer before bringing him on full time. However I would like certain customer names, other sensitive data within our visual studio solution to be "obfuscated" to him so that when he gets latest, etc., he does not see this sensitive information. Is there any way to rename certain strings when he checks code out to make certain strings appear as something else, but make it so that when I check code out these strings are replaced with their actual values?
I am afraid there is not such a feature in TFS.
Alternatively, you can create a new branch. And hide the sensitive information in this branch. Then let the new developer work on this specific branch. See Branch folders and files.
You can also change the security settings to allow the developer to access to this branch only. Go to project Settings-->Version Control(or Repositories) See below:
Related
What is a good learning resource for TFS and how to use TFS with Visual Studio?
Specifically, I want to know two things.
Exactly what are the step-by-steps procedures of checking in code. I know that I am required to do a code review. So, after the code review is done by a peer, I understand that this is not enough and the original developer has to click to do something to submit the code into the TFS system. I mean, I want to know precisely what buttons to click on.
I also want to know how to use Visual Studio to look up the actual version. How do I determine the details of what is already checked in?
There are many blogs videos in google. If you want a full detail resource, suggest you directly take a look at our official doc here -- Azure DevOps Server Documentation
A suggested learn order for your reference:
Installation (you could skip this if your company already done this)--
Code -- Build&Release -- Packages-- Test-- Work-- Analysis-- Admin
Tool
TFS supports two types of version control: Git and Team Foundation Version Control (TFVC). One centralized and one distributed. As for which version control system should you use, you could take a look at this thread: Choosing the right version control for your project
For your case, you could easy check the history in server side. It's called changeset in TFVC and commit in Git.
For example, when you check in your changes, they are stored on the server as a changeset. Changesets contain the history of each item in version control.
You can view a changeset to see what the exact file changes were, discover the owner's comments, find linked work items, and see if any policy warnings were triggered.
The same as Git, actually you could find the answer for both question 1&2 in Code part. Hope it helps.
I started using TFS since VS2010. By that time I already created my own TFS server (myname.visualstudio.com). My problem is that I created a new project on the my TFS website (the one with the dashboards). Then when I go to VS2017, and connect to that new project, it asks me to map and get it as expected. Instead of just clicking "Map & Get" button, I instead clicked advanced so that I can configure everything.
On the workspace configuration dialog, I noticed that VS names it as "MYPCBLABLA_1". If I try to remove the "_1", VS says that "the workspace blablabla already exists on computer blablabla", and does not let me use my existing workspace name.
Why does it do so? Can I not use only 1 workspace? From what I understand of workspaces, it is the container of my projects, so different workspace, different set of projects. But what are they really?
Additional info:
I don't know if this helps but on the past, I used to format my PC many times, I'm not sure if that affects the mappings or workspace names when I use VS after reformatting.
Workspaces are maybe the least well-understood feature in TFVC. And you are right in saying they're a way to isolate different sets of files from a TFVC repository.
A lot of people configure a new workspace for a specific project or set of solutions, but let's look at some of the ways workspaces can be used in detail:
Hotfixes: you may need to create a hotfix for something happening now, but you have pending changes in your existing workspace. Instead of shelving these changes, performing a "Get Specific version" on the bugged version, you can also create a new workspace in which to solve this particular problem. After completing the fix you can then continue working with the other workspace without needing to do anything.
Experiments: you may want to do some major refactoring, restructure source control or some other highly impactful operation. Doing this in a new (temporary) workspace helps you prevent messing up your normal work area.
Reviewing other peoples changes: When performing a review on another person's changes, you may want to have a local copy so you can run, annotate and play with the other person's code. Instead of taking these changes into your own workspace, you can easily bring these into a temporary workspace, which you can safely delete afterwards.
Performing a merge, while you are working on other changes: It may be the case that you're working on a new feature an already have some changes merged back to another branch when a release needs to be shipped. In order to prepare this release, without picking up changes or overwriting work in progress in your current workspace, it's often easier to perform these kinds of release activities in a temporary workspace, that way you know that the work is always done on the exact version in source control.
Preventing accidental changes to important branches: By putting your production branch in a separate workspace, you can't accidentally combine changes from say Development and Main into a single check-in. Since Visual Studio often auto-selects all pending changes in the workspace, this may cause unintended changes to your master/main branch. I've written a Check-in policy to prevent these issues, but having separate workspaces is a much safer solution.
Working with multiple developers on the same workstation/server: in some organisations, developers use a remote desktop to a central beefy server to do changes. To ensure each developer has his own set of files, each developer gets his/her own workspace. An alternative is to make the workspace public, which allows multiple developers to use the same workspace folder. But this often leads to all kinds of unexpected issues.
Browsing an old version of the code: if you need to review/compare an older version to a new one, you can often get away with the folder diff view in Visual Studio, but if you need to do more thorough comparisons, you may want to have 2 copies of the same folder in your TFVC repo. Creating two workspaces will allow you to have two different versions of the same folder on your local disk.
Prepare a special version for merges or labels: You can merge and label the workspace version of a set of files. You can create a workspace and then use Get Specific Version to fetch specific versions of specific files, these can all come from different changeset versions. Once you're satisfied, you can perform the label or merge or branch action to store this specific workspace version configuration on the server.
As you can see, Workspaces allow you to do parallel development on one machine, isolate changes etc.
Be creative
As you can see, workspaces are a very powerful concept. Usable for a lot of operations. But you need to understand the concept thoroughly. Many developers don't understand exactly what workspaces are and how they work, they're missing out of some of the most powerful concepts of TFVC.
Consolidating and cleaning up
In your case you now have two workspaces. In order to consolidate these (if you want to), you can unmap the folders from your _1 folder and then map these same folders in your original workspace. You can also delete the _1 workspace from the TFS Server and then update the mappings of the original workspace.
Remember that workspaces are stored on your local machine, but that the TFS server also has a registry of who mapped which TFVC folders to which workstations. So simply deleting files from your local disk is not sufficient. You need to save these changes to the TFS server (this happens automatically after performing a get operation after changing the mappings).
To check which workspaces are registered to your workstation on the TFS server, use:
tf vc workspaces /computer:YOURWORKSTATIONNAME
Then delete old workspaces with
// DELETE the local workspace
tf vc workspace /delete:WORKSPACENAME
// DELETE the workspace registration on the TFS server
tf vc workspaces /remove:WORKSPACENAME
To prevent the creation of a new workspace by VS, I:
Create a local folder to which I’ll map the content of the remote repository;
In VS, connect to the remote repository;
In VS, open Source Control Explorer and navigate to the content I need; VS will show a “not mapped message”.
Click on that message and map locally.
This guarantees that no other workspace will be created, and the current one will be used.
I work on a project that has a series of configuration files. From time to time, these files need to be updated with new properties or settings, or we update how content is stored in some of these fields. This means that we need to update these files to our project source control since we need to push these changes to all of the devs on this project, when these changes occur.
However, 95% of the time we want to ignore the changes in our local configs because they contain data-specific changes that are specific to a particular developer or his machine.
What I'd like to do within TFS is choose whether to commit the changes in these configuration files, or not, with each upload. Preferably, I'd never commit my personal changes (as they relate to my personal, localized data.) However, if I unstage this work, I can't switch branches until the changes are committed. If I undo the work, it's quite a pain to switch branches and then manually recreate all of those personal changes.
Is there away in TFS to store a set of changes, and when I update or switch my local branch, re-apply the changes to my local working set? Also, I don't need TFS to ignore these file-changes. Sometimes I do need to upload changes, especially when we're adding new config keys or changing the structure of the data. In such a case, I push up my file and everyone else will see the change in structure. However, if we can all apply localized patches to the specific regions/portions of the files with our user-specific code, it will save us a lot of time in re-integrating these files into our local, working projects. Can this be done?
According to your description, you could use shelvesets to handle the situation.
Since some of the pending changes that are not ready for check in, you could suspend your work and work on a different task/branch.
You can move your pending changes to a shelveset on the server and then clean your workspace. The shelveset saves and stores not only your file revisions, but also the Comment, the list of Related Work Items, and check-in notes (if you evaluate policies before shelving).
After the work have done, you could resume the shelveset to pending changes, unsheveset to local and keep working on it.
You could do this either from VS IDE or tf command line, more details please refer this tutorial: Suspend your work and manage your shelvesets
Does anyone know, if there is a possibility, to show the date of the check-out in the check-in dialog?
This would have the advantage for me, if i want to check-in all files with a known date of the checkout, e.g. all files i checked out today, than i could just sort them instead of search them and compare every single file.
It is not unusual that my list of checked out files becomes a bit longer until i am able to check them in again.
Thanks in advance for any suggestions.
I don't believe this is possible within VS. However, if you install TFS Power Tools, you should be able to perform a check-in from Windows Explorer; then (and this is by no means an exact science) you could sort by Date Created. I believe this should give you what you want.
A possibly better way to do this would be to make use of multiple workspaces. If you're working on things that can be independently checked in, then separating them using workspaces seems to make more sense; this also prevents the possibility of you booking in some changes that rely on other changes that you may have done on a different day.
I know you are on TFS2010 and possibly VS2010 but in VS 2012/Team Explorer Everywhere you have the option of excluding and Including files during check-in. YOu should probably check it out.
Check this link below:
http://msdn.microsoft.com/en-us/library/jj155786.aspx
There are some files in my team's solution that almost never need to be checked in. Each one of us has a slightly different version of these files (ex: configuration files pointing to our individual development database or slightly modified app.config). Therefore, these files are permanently present in the pending changes view.
Is it possible to hide these pending changes so we never check them in by mistake?
Here How can I always block checkin of a specific file in TFS are some options named. To not see your changes, you should follow the workspace approach.