I have a solution containing a bunch of projects all under source control that is mapped to a local folder on a PC, but only for a specific windows user, say UserA.
Now if I log into Windows under a different user UserB I want to be able to use the same code with the same source control, without overwriting any local files (e.g. with the server version. There have been many local changes that haven't been checked in by UserA).
However when I open the solution file as UserB, I get an error saying:
The solution appears to be under source control, but its binding information cannot be found. Because it is not possible to recover this missing information automatically, the projects whose bindings are missing will be treated as not under source control
(this applies to all projects)
The next message box gives me a choice between Temporarily working out of source control or Permanently removing the bindings.
Any attempt to Map the Server folder to the local folder will result in an error stating it's already mapped. Also I said I want to use the existing local code while keeping it under source control (e.g. so UserB can check in the changes and any more changes he makes)
What is the correct way to do this?
If I have understood you correctly, you want to use two users coding in same machine with source control.
You just need to create a local mapping of the source files to a different workspace folder. More detail step for your reference:In TFS, how can I share source files in different location, in same machine, without sharing the full project
Now you have two copies of your soucre files but with different workspace in your dev machine . When "User B" want to use these files on your machine, he just need to select the new workspace to work on it.
However, if you want userB to use the local file mappinged by userA(e.g. with the server version. There have been many local changes that haven't been checked in by UserA) It's impossible and also run counter to the rules of TFS. You must check in the local changes made by userA first, then get the lastest version from server for userB.
To share a workspace on one computer between different users, you need to change the advanced permissions of the workspace from Private Workspace to Public Workspace.
This can only be done by the owner of the workspace, which is UserA in your scenario. See the question How do I choose advanced workspace options? for more information.
Related
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.
In my scenario, I have two people that do work on the same code base. Their only available workspace is a shared dev environment (where the files built are used to host the dev version of the site to boot). As such, they perform their work directly in that location. I've recently introduced source control to the project, and turned that location into a Git repository.
Let me preface by saying: Yes, I would love it if the dev host spot was a deploy-to spot, and these people had their own local copies of the source code. But that isn't feasible right now.
My question: Is it possible for two different Windows users/Git users (they have separate accounts that they can use to interact with GitHub/etc. with) to share the same folder? My hope would be that SourceTree (our weapon of choice) or Git, at least, wouldn't have a problem with this: Just show diffs of what's changed, and use the currently-logged-in user's information when making commits/other actions.
It looks like that while SourceTree has separate installation directories, it still embeds some account information in the .git folder itself. When I try to interact with Git (via a pull for example), it first tries to prompt for new credentials/etc., but shortly thereafter it says "please enter password for {other-user}" without an option to hop usernames.
It looks like we'll just have to do things the right way after all. Painful (for them) but no choice.
My Visual Studio projects are located in C:\Users\MyName\ProjectName.
To make life easier (I thought), I created a file system link in the root called TFS.
(i.e. C:\TFS points to C:\Users\MyName\Projects)
I always open my projects from the link (i.e. C:\Tfs\ProjectName\ProjectName.sln) and my TFS local paths uses the link.
This work fine most of the time but someVisual Studio and TFS think files are in C:\Users\MyName...
i.e. If I look at the properties of projects in a solution, one can be in C:\Tfs and another in C:\Users. I have verified that there are no absolute paths in any solution or project files.
When this happen and I add a new file to a project TFS becomes a real mess. TFS thinks the new file is in C:\Users and is not versions controlled but at the same time there is a file with the same name in the C:\TFS folder so I need to resolve a conflict. I can resolve the conflict but TFS starts versioning the C:\Users file. i.e. the local folder for the project is C:\TFS... but according to TFS (and pending changes) the new files live in C:\Users.
I have not found a way to change the local name of file, only a folder.
Is there a way to resolve this or should I just get rid of the link?
(It works slightly better with a TFS local workspace but the problem is still there)
<tl;dr>
Symlinks are funny things and because TFVC stores binding information outside of the source control folder, it may get very confused when your repository is stored in or includes them.
Details
Opposed to Git, Mercurial and Subversion, TFVC doesn't just keep the binding of disk to repository in a subfolder of the repository (in case of a server workspace it doesn't keep this data on disk with the repository at all). It also stores it in a number of other places, namely the TFS server and your user profile.
When you look at a subversion or git repository you'll find the .svn or .git folders which contain the information of which folders on disk map to the repository.
With TFVC this information is not only stored on disk (in case of Local workspaces), but also on the server (machine name, server path, local path) and in your user profile (under AppData\Local\Microsoft\TeamFoundation\). These configurations store the full paths and these are used to see if a file is under version control or not. The reason why Local workspaces improve things, is because they add the tf$ folder with some of the binding information.
Since a workspace mapping can map a folder in your repository only to one folder on disk, the use of symlinks confuses the TFVC client. You might consider this a bug, since Microsoft should be able to resolve the link (depending on the link type), but Visual Studio assumes you are not using links. Other reasons why this (potentially) confuses Visual Studio is that file size and other attribute changes are not always signaled in case links are used (date changed and file size may not be notified until Visual Studio is told to refresh the solution). The Read-Only bit (which TFVC uses in case of server workspaces) also has special behavior in case links are used and may cause issues of undetected checkouts.
More on the strange edge cases caused by links, can be found here.
I'm not sure why you'd want to use a link in this case, the sources are already stored in TFS, so a backup of your profile doesn't add much and only makes you system slower in case you have a roaming profile. Plus, workspaces are machine bound and should never "move between machines" magically anyway.
You can submit a suggestion on the Visual Studio User Voice, or file a bug on Connect if you want to see this behavior changed, but to solve your problem, use normal folders and map your files to a unique location.
Just keep in mind, very few applications in Windows are built to handle Symlinks, and those that are may cause strange behaviors. Windows explorer (file open dialogs and drag&drop) may provide the original file location, instead of the link location for certain actions and changes to attributes in one location may not be visible in the linked location.
As you can see here, systems will be able to see the difference between symlinks and real directories, and thus may act on that knowledge:
As usual I extensively searched for a solution before asking here, I'm really stuck.
I'm currently working on a customer TFS server and I have no administration rights whatsoever. Me and a colleague were using the same user account, which I know is a bad practice but again I had no choice here.
Today we found out that the account is expired and the customer is saying that it will not be reactivated. Instead they gave us a new account.
The problem is that in our local workspaces we had some uncommited changes. I'm trying to find a way to reassing the local workspace to a different user but every path I tried leads to a dead end.
One thing I tried was to access the current workspace and set it to "Public" so another user can work on it, but I can't access the current workspace as I am offline and the user is expired.
If I change TFS credentials and try to Get Latest Version or anything else I don't see the old workspace but only the workspace(s) of the new user, which has no "Use" access to my local workspace.
I also read that a manual merge of the changes (using KDiff or Winmerge) is discouraged as TFS doesn't see edits done outside VS so it wouldn't know the files have been modified. I personally noted this behaviour when I tried to change some nodes in .csproj files with Notepad++ and TFS didn't give me the file in the pending changes.
Anyone knows the proper way to work with a new user without losing the local changes?
Thanks.
1)Create a branch for the latest change set from the server
2) Check out the files to your workspace
3) Overwrite the files in worspace
4) Now the branch contains your changes
5) Merge the branch which contains your chnages with the latest.
You have three options:
If you are using TFS 2012+ and VS 2012+ you can create a new workspace as the new user and make it a 'local' workspace rather than a server workspace. Then just drop the changes in a VS will detect them.
If you are using an old version of TFS and/or VS you can use the 'go online' option (2010 only)
If you are using a really old version you may need to checkout the entire workspace before dropping the changes back in.
Update: In order to achieve a merge of the changes you could create a branch from the last/latest changeset that you 'got' from the server. Then just overwrite you files... You now have a branch with just your changes and you can then user the merge tool to stitch it back together.
note: Also note that you should check in code frequently (at least daily) to avoid this issue in the first place.
In my company 3 developers use PhpStorm for developing WebApps.
Everyone needs to open (not simultaneously) a project an other user created from time to time.
Let's say user A uses a deployment server named server A and user B uses server b.
User A created the project in the deployment.xml server A is saved.
Now user B needs to open the project and creates server B. Now server B is saved in deployment.xml
If user A want to reopen the project again, he has to set the server back to server A.
Same goes for the workspace.xml.
My question is if it possible to use different project settings for user A and user B?
If it is possible what do I need to change in my settings?
If not how can 3 users work together (no VCS)?
Thanks in advance
In the case where no settings are to be shared between developers, only the project files, PhpStorm accepts reading project files from a directory outside of the classical 'project directory'. Here is one approach to that; each developer is to:
Create and open a new empty project from PhpStorm, in a folder on the local hard drive. Only project settings will be stored here.
Open the Settings dialog, choose 'Directories' from the left pane, then click 'Add Content Root' (at the top of the rightmost pane).
Choose the folder on the network share that contains the project files.
Remove the original 'content root' corresponding to the project settings folder on the local hard drive.
Each developer can now open their locally created directory in PhpStorm, and any files opened/created will exist on the shared folder.
A related question: PhpStorm - How can I avoid creating the .idea folder?
Please note that working with files that are not on a local filesystem, especially when they are editable by multiple developers, is not recommended. Even for small projects, storing a Git repository on the network share, with each developer git pulling when beginning work and git pushing when done, is a small investment that will pay large dividends. Here is a good introduction: http://www.gitguys.com/topics/creating-a-shared-repository-users-sharing-the-repository/, but the key command is git init --bare reponame in the setup phase.