I don't want VS to fiddle with git, I use sourcetree for that, so I set the source control provider in the tools -> options -> source control to none.
As soon as you open a project that has git versioning on it the setting automatically switches back to git source control provider.
How to permanantly disable it?
I'm using visual studio 2013 update 5.
I found that I had this problem, even for projects that have never had anything to do with git. It started when I initialized a git repo in my C:\Users\<username> directory, and it went away wen I deleted the .git\ folder from that repo.
Just found an answer in a blog:
http://researchaholic.com/2015/02/02/remove-the-microsoft-gitprovider-from-visual-studio-2013/
To remove the git provider altogether one can delete the key
11b8e6d7-c08b-4385-b321-321078cdd1f8
from the registry via regedit:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\12.0_Config\SourceControlProviders
note that you completely remove it, so only for people not interested in a CPU eating annoying ms-plugin.
I also found it does this, if you keep all of your source code in one base folder (in my case D:\Source). I have my TFS "root" mapped to D:\Source<project name>. As it turns out, I downloaded some sample Xamarin project from Microsoft using git & started in the D:\Source\ folder, which created the D:\Source.git folder. After creating this folder, it assumed anything that was a peer/sibling to that folder was a git repo.
Deleting this .git folder in my TFS path fixed it for me.
Related
I have a project where the repository was on a disk that now is faulty.
so I have created a new repo folder in file explorer on a new disk.
I then deleted the .svn folder in my project as I thought that would make it like a fresh project (obviously I was wrong about that)
as It still wont add the project to the new repo with error "Project not added to Subversion because it is out of working copy"
It doesn't even ask where I want to create the Repo so somehow the project still has the old address.
I also altered my .sln solution file changing Svn-Managed to = False
The Old repo is gone and I'm using a backup that has been altered in the past.
Could anyone help me get round this please
Mike
I'm afraid that your case is unclear and maybe several screenshots and details about your environment will help (solution directories layout, versions of VisualSVN, TortoiseSVN, Visual Studio).
If you want to add your solution into a new repository, run the Extensions | VisualSVN | Add Solution to Subversion command and follow the steps of the wizard. If you receive warnings, please examine them and update your question with these details. Note that you need to svn commit your solution to publish your solution's data into a repository.
Additional notes:
Removing the .svn directory from a working copy effectively unties the directory from Subversion. I.e., this action unversions the working copy. Note that up-to-date VisualSVN and Subversion versions place only one .svn directory at the root of a working copy. But SVN 1.6 and older have this directory in every folder of a working copy.
If you want to re-add an existing solution to a new repository, then indeed you could remove the .svn directory or run svn export from the working copy into a new directory - this creates an unversioned copy of your working copy. Note that you may need to re-open your Visual Studio solution after removing the .svn directory.
The command Add Solution to Subversion is only active if the opened solution is not in a working copy (i.e., when it is not versioned). If the command is greyed out, then you need to unversion your solution first. See TortoiseSVN Manual | Exporting a Subversion working copy (section Removing a working copy from version control at the bottom of the page).
VisualSVN does not place the Svn-Managed to = False string into your solution's .sln file. VisualSVN does not depend on it. I assume that this string was recorded by another Visual Studio plug-in.
Visual Studio 2019
TSVN 4.8.53
(tried also with VisualSVN 7.2.0 )
TortoiseSVN installed with command line tools
I want to see in Pending changes from TSVN only the changes for current solution. Instead I see all the changes from the entire checkout folder.
In Options => Windows= > Options, at "working copy root path" it is put the path of the checkout folder.
I remembered I used this extension successfully with VS2017
Do you any idea what could be?
UPDATED (26.11.2019)
It seems I cannot make TSVN or VisualSVN to work in an elegant way. I can set the working copy on each project to point to my solution folder, but:
1. I have more than 300 projects.
2. It modifies the source files
I tried to contact the support from both extension but still no answer
you can find the setting in Extensions>VisualSVN>Set working copy root. Uncheck "determine working copy automatically":
I deleted a local copy of a TFS source-code branch (actually I renamed the branch and had to delete the old-named version), but Source Control Explorer window in Visual Studio says I still have the latest version so whenever I double-click a file, I get an error that the file doesn't exist.
Is TFS supposed to notice when I delete a local working copy i.e. this is a glitch?
How can I address it? Get the latest version and then delete it?
Is TFS supposed to notice when I delete a local working copy...?
No. TFS TFVC expects that it controls your working directories, at least with a Server Workspace. When you start doing things without telling it, then it has no idea.
If you want to remove files from your local drive, do a get of changeset 0 on that path (where the files won't be) and/or delete your working folder mapping or delete the TFS workspace.
Why does it work this way? Performance. If you have 10+ GB of sources, you can't afford to have your version control system scanning your filesystem to try to figure out what you've done. That's why TFVC Server Workspaces work this way.
Change your workspace to a Local Workspace if you have only a small bit of source code and you want to scan the filesystem for changes. Or switch to Git in TFS if you want a complete distributed experience.
I came from Eclipse background and I am apparently missing something.
There is an existing GitHub project with JS code in it and I would like to start adding TypeScript nature to it, one type at a time.
I have followed this tutorial to clone project from GitHub to my "local git repository". Now the Team Explorer window displays it as local repository and I can commit changes etc but it's not a project and I don't know how to open it as a project (I want to open it as TypeScript project).
The workflow I was used to from Eclipse would simply be New -> Other -> SVN -> Checkout Projects from SVN that is automatically followed by New Project Wizard.
How do I clone existing JS project from GitHub and make it a TypeScrip project while keeping the existing folder structure?
EDIT: I am using Visual Studio Express and I am limited to the native Git extension.
What I typically do in this situation;
Clone repository using Git in Visual Studio; or use GitHub for Windows and Clone in Desktop from the Git project's web page. This will create a directory (repository) with the project files where you specify.
In visual studio, File->New->create a new project from existing code. From the wizard, select C# or C++ (whatever your choice it does not really matter)
The wizard requires a project file location: give the location of the Git folder that contains the project files (where you cloned the project's repository).
The Wizard requires a unique project name, for example you can use the name of the Git project with VisualStudio (or VS) appended to the end.
Git will now be in sync and you will be able to see all the git files. Making changes will check them out and allow you to push them to the project etc...
***** By default Git will want to check in the newly created .csproj file that Visual Studio creates to allow you to open the project in Visual Studio. You will just want to drag this into the excluded changes section because most likely the project in question will not be using Visual Studio.**
I solved this by opening the site as a website. File->Open->Website.
No Project Files/Solution files required. It just opens up the folder in the solution explorer.
To make it a typescript project, just add a tsconfig.json file to the directory.
Do you have any code in that repository yet that you want to open? I'm guessing not in which case you need to create a new VS project (just like you'd create a new Eclipse project and have it in your workspace)
Go to File, New..., Project... and pick the project type that you want. Give the project a name and set the location to be a folder INSIDE the folder that you cloned your Git repo to earlier (i.e. c:\mycode\mygitproject). Also give your solution a name. A "Solution" in Visual Studio is a wrapper for the projects inside it, kinda like the closest thing to a workspace or a working set in Eclipse but not quite the same thing.
Then Visual Studio should then be smart enough to pick up that this is in Git repo and allow you to commit locally as well as push/pull to GitHub etc.
Finally, while I work with the team that created the Visual Studio Tools for Git, I'd still highly recommend that you get hold of a command line should you want to do some more powerful stuff with Git other than simply committing code, push/pulling changes and branching or merging branches. If you are working against GitHub then you might also want to install GitHub for Windows which will bring some Git tools with it or you can install Git for Windows and also install Posh-Git separately. All of these things work together and give you the maximum power of Git but you can pick and choose the tool that works best for you. You'll probably find a workflow of Clone using GitHub for Windows, commit/push/pull/branch/merge in VS and then Posh-Git if you do more advanced stuff or want to hand-tweak settings.
I am using Visual Studio 2010 to develop an MVC 3 application for Azure. We are using AnkhSVN for subversion control, which has been slightly buggy in the past.
The error I'm getting when I try and Build/Debug my application is:
Unable to copy file "C:\Xxx_bin_deployableAssemblies.svn\all-wcprops" to "bin\.svn\all-wcprops". Access to the path 'bin\.svn\all-wcprops' is denied.
The story gets more convoluted, since this error is not thrown on another one of our developer machines, just on mine. The only real difference in our machines is that I have SP1 installed on mine.
Also when I updated AnkhSVN and re-checked out the app from the subversion server it work without throwing an error for the first build. After shutting my comp and then starting back up there error popped back up again.
Update:
I still haven't found a real solution. I just delete the .svn file in the folder and that takes care of the issue with Building the app. However, when I update or commit it throws an unversioned error.
I think the problem is that the app is trying to copy the .svn file over during the build, instead of just ignoring.
Do you know of any way to have the .svn file to be explicitly excluded from the build?
I need to resolve this issue asap, so any help is great!
Thanks
I received the same errors after I versioned my MVC 3 app for Azure on VS 2010 SP1. I was able to resolve this issue in three simple steps.
1.) From the VS 2010 Solution Explorer, click 'Show All Files'. This will show the hidden 'bin' and 'obj' folders in your Web/Worker role project. Right-click and delete both 'bin' and 'obj' folders.
2.) In Windows Explorer, browse to the folder that is versioned (should be your root solution folder). Right-click -> 'SVN Update'. This will download and put back the 'bin' and 'obj' folders that you deleted in VS. This is necessary because your project will exclude these folders from the solution, however SVN will still think they are part of it.
3.) The final step is to delete these files from your repository. In Windows Explorer, browse to the project that contains the 'bin' and 'obj' folder. Select the 'bin' and 'obj' folder -> right-click -> TortoiseSVN -> Delete. Go back to the root versioned folder and SVN commit to remove them from the repository.
The next time you build your Solution, the 'bin' and 'obj' folders will be recreated. Just make sure you don't add or commit them to your repository.
I fixed this problem by going into Windows Explorer and changing the properties of the folder to not index (look in advanced settings) and then manually copying the files giving me errors.
I had the same problem and fixed it.
You have your build output checked into SVN. This Azure target (that's complaining) should only be messing with \bin, \obj directories during a build. It will be cleaning and building. This clashes with .svn as source controlled files under .svn have hidden files and folders with read-only access. Therefore the build runs and subsequently breaks when the Azure targets try to delete/move the .svn files.
To fix just remove your build output from SVN (anything in \bin or \obj). You should not be placing these files into source control anyway as the rest of the files in SVN produce this output, so there is no reason to save it separately. Then you can delete the bin/obj etc folders and you should no longer experience the issue.
If you just delete the bin and obj files as other people have suggested then you're just leaving the problem for the next poor sucker that checks out a clean.
I had the same problem. It appear that the project bin folder was "accidentally" also committed into the svn. After removing the bin which of course shouldn't be in the svn the problem was solved.
Now it is still needed to understand why the build try to copy the sv folder to the bin.
Somehow another application keeps the file locked while Subversion (below AnkhSVN) tries to replace it with a different version.
Usually this is caused by a virus or index scanner. Retrying a bit later usually resolves this issue.
Sometimes a Subversion "Cleanup" (Solution explorer->(relevant node, E.g. Solution)->Subversion->Cleanup) is required to recover from similar errors.
I also had this problem. The cause for me was that I had created the bin directory myself instead of letting VS create the bin directory. Once I deleted the bin directory cleaned the build and did a rebuild, everything worked fine.