I have set up a number of projects on Git VSTS, and all was fine.
I then tried to add another solution to source control today, but the status bar along the bottom said it was already under one of the previous source control projects I set up - which is in a sibling folder.
The File->Source Control menu item was missing so I couldn't look at bindings or anything.
In the end, I moved all the projects and solution files to a differently named folder, and the normal status bar "Add to source control" item came back.
My question is, why does moving the files work? There were no hidden .git or .vs folders - this solution had never been added to source control before.
What is it doing? Is there a way to fix this if it happens again without renaming the solution folder?
Additional info: I tried disconnecting from TFS and opening the project I wanted to add, but that had no effect - so I presume that's because it thinks it's using the local git repository?
If I look at Team Explorer once disconnected from TFS, then all remote repositories are disconnected as I'd expect, but the local Git one the common code repository is bold still as the current repository - and there seems to be no way of disconnecting from local repositories?
You may try to clean the cache folder to see whether it helps you. The folder path is: C:\Users\username\AppData\Local\Microsoft\Team Foundation\x.0\Cache.
Related
Had to move my directories for the local workspaces for Visual Studio. I updated the directory locations in VS, but it acted as if they were completely out of sync, and asked to get latest.
I let it do so for one project - it (re)downloaded everything, came up with a list of files to which I had local changes, listing them as conflicts. I kept the local version of all the files, so no work was lost. But when I opened the project, those files came up as not being in source control, and it offered to let me add them. So again, I have all my work, but that's a tedious process to re-connect everything. Not to mention that I'm not sure I caught ALL the files that needed re-adding.
I've also considered copying everything to other directories, download a clean copy of the project(s), doing a compare and folding in my changes. Still messy, but possibly safer.
Is there a far better way to do this practice that I've missed? Perhaps as a side question, is there an easy way to list all the files in a project not in source control?
Guess you moved/changed local TFS workspace folders in file system directly. This caused some folders/sub-folders/files lost mapping.
In other words, all of these folders already out of source control. That's why you need to re-add or re-connect them to TFS source control.
A right way please refer how to move an item in TFVC:
You can use Source Control Explorer to move one file or folder at a
time. You should not use Source Control Explorer to move folders or
files that are referenced by a Visual Studio project or solution. Move
these files with Solution Explorer instead and check in the move in a
new changeset.
In Source Control Explorer, select the item that you want to move,
open its shortcut menu, and choose Move.
In the Move dialog box, either manually type the destination for the
item in the To box, or choose Browse to use the Browse for Folder
dialog box.
Choose OK.
Move is actually a delete and re-add process. You could also take a look at this similar question here: Moving project (under source control) to different folder
In your situation, a quick way to solve the conflicts should be: First back up your local files, delete your old workspace, create a totally new workspace. Get latest version from sever side to your new workspace.
Then copy your back-up files/folders which copied from old workspace folder to the new one. Windows system will judge to replace files and add new files.(It may take some time) After this, TFS system will auto detect the changes in local and will list them as new pending changes. Some new add files maybe stay in the Excluded list, manually promote them in Included list.
Finally check in all your pending changes, everything should get back on track.
We are working with building ETL packages in SSIS using a TFS repository. When my collegue add new files to the repository they are not added properly to the repository even though he checks in the entire project file. He sees the files in his project folder, and it looks like everything is checked in. But when I click on "Get latest version" I get a warning that the package is missing from the project directory. If any of us then try to add the file again we get a warning that the file all redy exists, even though it is not visible in my folders. Right now the solution we are using is for him to delete the file and then commit the change. After he deletes the file I get the latest version. Then he sends me the files and then I add them to the repository. Once I have added the files things seem to work as expected. Has anyone else had this problem, and know of a solution?
UPDATE:
The solution we found now is that I have to go to the local folder and find the new file my colegue added. Then I right click the file he just added and select add to project. Then the new file is visible in my version, but it does not have a blue lock icon next to it. If I then double click the sln-file to reload the project the blue lock icon is visible to me.
It is still not an optimal solution, but it works a lot better than him having to send me the file so I could check it in.
Is this the way TFS is supposed to work?
Can you please check the mapped work space path in your local machine there you will find the checked code. You need to manually Add.
Right Click on SSIS package -->AddExisting Package--> Select the package from Workspace-->Ok
Now you will find the missing package in your Solution Explorer as well.
If you are using TFVC.
Open Source Control Explorer=>Right click that solution/project folder=>View History, then check the related ChangeSet whether he add the file correctly.
Let your college to check the permission of that folder/file: Right click the folder/file->Advanced=>Security.
Regards
I recently refactored an old project and altered its file/folder structure, which has caused big problems checking in. I can't check-in pending changes because parent folders have pending changes along with their children. I've tried checking in groups of changes at a time but to no avail.
Is there a way to reset the source control without erasing my TFS work items and change history?
if everything is as you want it in TFS, you can delete Your local workspace, to clear any files you have locally.
You can then goto to Advanced>Source Control and choose specific Version.
tick both boxes and click ok
when refactoring folder structures within TFS you are best to use the move function of TFS, (shown in first Pic). Move your folders, this way TFS will retain history, then open the solution and remap any projects that have moved
My team and I started a project at Azure and we have a git as the VCS/SCM.
One of my partners had made a few changes, and he had commited them. When I try to get those changes at my local repository, and I press sync at the Visual Studio, the following message appears
Cannot merge because there are uncommitted changes. Commit or undo
your changes before merging again. See the Output window for details.
The output window shows the message below
Cannot complete the operation because of existing changes to the
following file:Project\Project.csproj
I have searched everywhere at google, but I did not find anything similar.
Can anyone help me with this?
We are stack.
Thanks a lot
It probably means VisualStudio automatically added some references to the file ProjectProject.csproj, where it keeps general project settings. In VisualStudio 2013 you may do:
Go to the TeamExplorer
Select "Changes"
Search through Included and Excluded Changes, .csproj file is probably there
Right click on it and select compare with unchanged to see the differences
Now choose to commit it or undo the changes (if, for example, the changes are not necessary) to be able to sync with the current repository.
I had this same dilemma and it turned out that somehow the file that was preventing me from switching branches and was in my solution, was not being tracked like the other files were. I just added it to source control via the explorer window, committed and pushed it, then I was able to switch branches just fine. Hope this helps.
Are there any good techniques to help us know which branch (or trunk) our working copy is from? We recently converted to Subversion and we're using release branches. I had two developers commit changes to the release branch that should have been committed to the trunk. We're using CI (TeamCity), so I recognized the problem right away and was able to revert the changes but I'd like to prevent it from happening again. From within Visual Studio, especially, it's easy to make a mistake and commit to the wrong branch.
We're using TortoiseSVN and AnkhSVN.
Edited to add:
Just to clarify, I'm looking for a method to prevent careless mistakes, I already know how to find this information. There are two careless mistakes I'm trying to prevent:
Doing work on the wrong branch. If this is caught before commit, the developer has to merge the changes back into the correct branch.
Committing to the wrong branch. This combines the pain of point 1 with having to revert the changes in Subversion.
Edited to add: We just made the switch to the VisualSVN VS plugin and it has a toolbar that displays the path of the current working copy. I really like the reassurance that I'm working on the right branch.
Perhaps you should consider using a pre-commit hook: http://svnbook.red-bean.com/nightly/en/svn.reposadmin.create.html
Then you could do something like only approve checkins that have 'for release' in the comments for that particular branch or something like that and return an error message otherwise.
In AnkhSVN (in Visual Studio) the project url of your working copy is from is displayed in the 'Working on' field of the Pending Changes Window (View->Pending Changes).
The url of a file/folder is also displayed in the Visual Studio project window when you select a file in the Pending Changes Window or Working Copy Explorer (and in many cases even when you select a file in the Solution explorer; but this depends on the project type).
[Update: I just added AnkhSVN issue #581 for extension of the commit dialog.]
Tortoise SVN adds columns to the Windows Explorer view. In "Details" mode, right-click on column headers to get a list of available columns, at the bottom, select "More" to get a dialog of all available column types.
SVN short URL should quickly show you what the location is in the repository.
But this doesn't appear to work under vista ...
Right click the folder, move to the subversion tab, there it says the project it's linked to.
Also, in the commit dialog, it says so at the top of the dialog.
From the working directory:
svn info
URL will contain the branch your working directory points to.
<EDIT> Seeing how many people dislike the command line, the closes thing I found from TortoiseSVN is the "repo browser" which seems to use the selected branch as your starting path in the repo. </EDIT>
Avoid re-using working copies. If you're working on 2 places in the repository, have 2 working copies, named appropriately, like: Project-trunk, Project-release.
Here is a simple idea which might help:
Create an empty text file named "branch_XX" (or any name) and add it to your branch.
commit this and then when you switch to the trunk, the file will not appear in the solution explorer.
It sounds stupid... but it does the trick.
I really hope they will add something that might mark what branch we are using without going to other windows.
In AnkhSVN (in Visual Studio), right click on your project/solution, then Source Control -> Subversion -> Select in Repository Explorer. It will automatically select the branch you're currently working on (i.e. the branch you're switched to).
I don't think that the accepted answer for AnkhSVN works for Projects, since I always see the same URL in the "Pending Changes" even after I use the option "Switch Project" on a project.