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:
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.
This is a very simple question - How can I remove Source Control from my solution and projects in order to change the SVN repository ?
I have an old project linked to an old repository, trying to move to a new one, and unable to figure out how.
The Actual place in Visual Studio that suppose to enable this is Grayed out.
Removing the .svn files form the folder doesn't apply as they are not there....
using the latest version of ankhSVN.
In your Visual2013. Go--> Tool----> Optioins--->sourcesControl
And Cuurent Sources Plug in None.
just set This. if not retuen feedback...
You seem to want to change the SVN respository that you're pointing to. There is another Question And Answer, but it seems pretty ugly.
Having installed the latest version of ankhSVN on Visual Studio 2013, it seems pretty trivial to relocate to a different SVN respository.
Right click on the Solution -> Subversion -> Switch Solution
On the menu, you should have an entry pointing to the current location of the solution. If the repository is the same, but under a different URL e.g. changing hostname, directory, etc, then simply change the relevant pieces in the URL and hit enter.
It will prompt you that the root you've specified is different from the one that you're currently using and you can simply relocate it from one to the other - i.e. choose to relocate. It will then prompt you a second time to switch, but this should be a free change.
If the new repository is different to the old one i.e. it's somewhere completely different in a different repository with a different repository ID then you're going to have to do some form of manual changing by following the instructions on the other answer.
If you want to remove the svn metadata for the project, it's in a single directory called .svn at the root of the solution that was checked out from subversion, as well as removing the information in the .sln file that mentions AnkhSVN (it's probably the only entries mentioned in a specific GlobalSection in the file mentioning source control). That purges all the svn data from the solution.
We have multiple developers on our team. This works for everyone except one developer, but we cannot seem to find the reason it does not work for this individual. We all have VS premium+, TFS 2012 power tools installed.
We have a branch. We get latest version from branch. Go to windows explorer and delete all files in folder "sdk" (there exist no subdirectories in sdk/). Then we copy into it a bunch of files. (This effectively leaves some files as new files, updated files, identical files or removed files when compared with what was deleted.)
When we go to pending changes, these changes show up under "Excluded Changes - Add(s) 51, Deletes(3)".
Except for one developer. His system does not recognize these changes. What might cause this to not work for him?
If it helps troubleshoot, he is also the only developer that if he were to delete these files via power tools delete option in windows explorer, his .dll files get locked. This does not happen for anyone else either.
This is what we've checked so far:
EDIT: Solution Found - Thank you all for the responses! It was indeed the local vs server workspace option. Setting his workspace to local solved these and a few other issue he was apparently having.
Make sure that the developer is using a "Local Workspace" as opposed to the "Server Workspace".
This is a concept which was introduced in TFS 2012 which helps developers to work offline as opposed to server workspace in earlier versions which did not allow that. TFS 2012 changes up the workspace options. Server workspaces are still available, and work exactly has they have in previous versions. However, TFS 2012 now contains a new type of workspace, called a Local workspace. Again, this is an oversimplification, but in a Local workspace, all the files are read/write, not read-only. The meta-data about the files is stored in a hidden folder in the root of the workspace, which allows edits, renames and deletes to be done locally without any communication to the server.
This improves the offline story with TFS significantly, as you no longer encounter issues with editing read-only files. It also makes it easier to work with other tools (such as Notepad) to edit code files. Making a change to a code file using Notepad will still mark that file as edited, which will be picked up by TFS the next time you connect.
LINK
This only ever happens when a user tampers with a local view of source control (be it a local workspace, or not). If all you ever did was get latest from TFS this would never occur, instead, the local view of what is in TFS would always be properly managed.
Also sounds like a bad merge, e.g. getting latest (where the files no longer exist) then copying in old content (introducing untracked files.) One thing you might try doing to correct the issue is doing a forced fetch from TFS after deleting the local workspace contents BEFORE attempting a merge. This will ensure that the local workspace is up to date an accurate with what the TFS server believes is truth, if it still occurs after merging in content then the problem is almost certainly within the merge process the user is going through (i.e. PEBKAC, or a knowledge gap about what they are doing.)
If you unshelve old content (pre-deletion) into the local workspace (where the deletions have already been performed, according to the SCC, and thus locally because of a sync/get-latest) then the unshelved files will effectively become untracked and it's up to the user to clean up the mess. This is identical to a user having copied loose files into their workspace that TFS never had any knowledge of. TFS isn't going to prune untracked files for you, I believe some other source control tools might do this as a configurable default, TFS does not.
That this is only happening to one developer in the team suggests that the other developers, one at a time, should sit with this developer and drive using "their process" to see if it still occurs for them. More often than not this comes down to a bad process a user has adopted, and putting a different person in the chair can help highlight why it has been occurring and help end it. A disciplined build/source manager and/or developer should not experience this problem.
Very interested in knowing what the problem turns out to be.
To start with some background, I am a member of a small team developing an ASP.NET application. In addition to us, there are 2 other teams working on it, all from different countries. Source code is hosted on a shared SVN server but there is no central testing environment. Each developer runs the app on their own machine and data services are set up per team.
Unfortunately our SVN workflow has some gaps in it: annoyances arise when there is time for an SVN update.
It is mainly because each developer and team have slightly different environments in terms of disk directory structure and configuration (both IIS and app itself). Hence conflicts in configuration files and elsewhere that in essence are not conflicts at all - for runtime configuration (XML) and in *.suo.
How should we handle this if our objective is to keep checkout, app setup and update as painless as possible?
One option would obviously be master copies. Another one establishing uniformity in developer environments and keeping it. But what about a third alternative?
One thing to do is to not put the .suo files into SVN, there's no reason to do that.
For IIS configuration there should be no argument - uniform environment across the build team.
For app.config files and the like, I tend to keep them in a separate "cfg" directory in the root of the project and use pre-build events to copy in the relevant ones I need depending on the project and environment I'm working on.
You could have a separate build task to copy in user-specific config into your output directory. Add a new directory in your root project called "user.config or something, and leave it empty. Then configure your project build to check this for entries and copy them to the output directory. This is easy to do, and then each dev can have their own config without affecting the master copies. Just make sure you have an ignore pattern on that folder so you don't commit user-specific configuration. If you have svnadmin access to your source code repo, you could set a hook to prevent it from ever happening.
Also set ignore patterns on your root directory (recursively) for .suo, .user, _Resharper or any other extensions you think are pertinent. There are some So questions already on exactly this topic:
Best general SVN Ignore Pattern?
Ignore *.suo and *.user files in svn. It is easy. After that create two types of config files in subversion. Development and Server, if in use add Test also. See below example.
ConnectionStringDevelopment.config
ConnectionStringServer.config
AppSettingsDevelopment.config
AppSettingsServer.config
Server files would contain server information. Development files is not contained in svn and ignored there. Every new developer will start by copying server files and making changes according to his environment.
Look following example site
http://code.google.com/p/karkas/source/browse/trunk/Karkas.Ornek/WebSite/web.config
following lines are interest.
<appSettings configSource="appSettingsDevelopment.config"/>
<connectionStrings configSource="ConnectionStringsDevelopment.config" />
ConfigSource can be used almost everywhere in web.config therefore you will be able to change every config to every developer. Only make use of following naming convention. ignore *Development.config in subversion. This way no developer config will be added to subversion.
Its not a perfect solution (and should only be used if there are not many of those special files), but what I do is to add fake files for each case, and switch the real file locally to it.
In detail: I have a file foo that creates the problem. I also create foo_1 and foo_2 and then locally switch foo to foo_1 (I use tortoisesvn, so I cant really give you the command line to do that). Then I am working on foo on my machine, but actually commit to foo_1. Other parties could then switch to foo_2...
(I admit this is basically a variant of the master-file approach you suggested yourself; but if there are not many actual changes to those files this at least reduces the numer of conflicts you have to think about)
2 projects under TFS Source Control.
DependancyProject.sln
AppProject.sln
With AppProject referencing DependancyProject.
-
The issue I have is with an Installer project in the AppProject.
It has DependancyProject.dll as a 'reference'(?) where it tries to include it in the GAC.
When I try to build this project, to create an MSI to install the App, I get the error
The item $/Assemblues/DependancyProject/bin/debug/DependancyProject.dll is locked for check-out by USER in workspace HIS-PC-NAME.
(The PC in question is not dead and not used)
The dll is not (as far as I can see) checked into Source Control.
The path it references anyway does not exist when I browse through it (no bin folder).
The DependancyProject is refernced by pretty much every project in Source Control, and i've never had any issues with it.
It builds, all the other projects build.
It's just this one Installer Project which doesn't.
And I can't see why it would need to try and modify it anyway.
All it needs to do (I'm assuming) is make a copy of it.
Any ideas here?
Some files are configured as "non-mergeable" in TFS, which means that they'll be locked when changes are pended on them. The default list includes a variety of binary files, including .dll files. Note that this lock applies to all pending changes - including adds.
It's likely that the other developer in question accidentally pended adds for his bin directory - and any binary files in that directory (ie, most of them) would have been locked as well due to being in that unmergeable list.
You will not be able to pend other changes (including an add in a different workspace) while these items are locked. To break this lock, the other developer can do this by undoing the pending changes, or a server administrator can do it using the Find in Source Control functionality in the Team Foundation Server Power Tools.
That said, I don't know why your build process is trying to pend an add on that file.
I had the same problem, and this guide solved all my problems.
The file was actually locked by me, but in a different work space (old computer).
Had to use the tf undo command to unlock the files.
If you are not going to use that workspace again, you can delete it by going to workspace pull down, selecting workspaces, and enabling the check box "Show remote workspaces". you can then select it and remove it.