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.
Related
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:
I haven't used SVN for quite awhile and now I need to add my project/solution to SVN in order to keep track of changes.
When I right click on the solution node in Visual Studio 2013, there are 2 options for me:
Add soluction to SVN
Add selected project to SVN.
My initial thought was I'd like to add all things under this solution to SVN, so I chose option 1.
But since then, I found that only the Visual Studio solution file has a SVN enabled tick in font of it, but for the rest of other files(.proj, .js, .cs, .html, .css etc.) they have no SVN enabled tick/icon/whatever the name is in front of them. So I guess they are not added into the SVN repository.
So my question is: what is the proper way to add my entire solution(not just solution file) into SVN?
Thank you.
Option 1 will work when there's a common root. This means a structure like:
Path\foo.sln
Path\project\project.csproj
Path\project\image.jpg
When there's no common root, it cannot be automatically created right now.
Hi I need to add the source files in my following project to Google Code SVN.
http://code.google.com/p/tnliveplaya/
I have installed AnkhSVN in visual studio 2010 and tried the "Add Solution to Subversion" but i dont have a clue on what to specify as the repo URL etc or any other necessary steps as this is my first time using Subversion or a subversion client. I referred the Google Code getting started guide too but that didnt help.
Please help if you know how to add a VS2010 solution to google code via AnkhSVN. :(
Subversion is pretty straight forward. You may want to read up on svn repository layout
Your repository has been set up with a solid layout with branches, tags, and a trunk directories.
Add your project to the trunk using this for your repository URL:
http://tnliveplaya.googlecode.com/svn/trunk
Profide your google code credentials.
Then you'll be shown a list of files that will be added. AnkhSVN is pretty smart at automatically ignoring files that shouldn't be checked in including items that change every build (e.g. obj and bin directories) or personal user settings (e.g. files ending with .user).
You can safely accept the defaults, changing them later if you wish. Read about svn:ignore.
It may take a while to commit if your project is large, but you should be good.
In showing a colleague how to use SVN yesterday, we created a test folder and file within our existing Visual Studio Solution. We'll call it "Test" folder with two files, "Test.ascx" and "Test.ascx.cs". We added it (or Visual SVN added it, 'cos it's awesome), and committed it. We also added and committed other files elsewhere in the project.
We can see it in the repository (and the other files).
Doing an update on my own machine to pull down these new files resulted in the other files being pulled down correctly, BUT the Test folder does not appear. No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
Where am I going wrong?
This is a known problem.
You can use
$ svn update --depth=infinity
to force the update. With TortoiseSVN, use the "Update to revision" command in the Submenu, then change the depth combobox to "fully recursive".
I've had ghost errors like this before and found the easiest work around is to delete the parent folder and update it's parent:
Project Root
Project
NewFolder
Delete Project, then Update Project Root
We can see it in the repository (and the other files).
...
No matter how many times I try Updating from various points in VS and in TortoiseSVN (urgh) Repo browser, it can't see that there are any changes to pull down.
So you can or cannot see it in the repository browser?
Did you commit and update the parent folder of your Test folder?
I don't know, svn is always telling me to clean, did you try that?
It's not an answer, I know, but I have tried all the solutions you guys have kindly suggested and I just end up with conflicts, crashed TortoiseSVN and built up Karma. Therefore, a trusty edit in the .svn/entries file sorted it.
I have until now been a single developer using SVN just to manage my source code. Other people don't have problems, and I just check in stuff. I use Visual SVN as a layer to frig SVN for .NET (which it isn't great with) and I seem to constantly run into issues. I am performing very simple operations, not even branching/tagging. Simple simple simple. And yet I have issues with it?
I am working on a large source base (approx 15K files) decomposed into about 25 projects. I want to keep the source in perforce (and am evaluating perforce to that end) but due to complications in the setup it isn't possible for me to keep the visual studio projects in source control, I know in theory the answer to this is to check the projects in, but that isn't feasible (we would end up with projects for several versions of VS checked in, and additionally several variants of each of these, instead they are generated automatically and this setup works very well).
Is there a way to get VS to checkout files for editing as it goes without adding the project to perforce, to avoid the user having to go to the perforce client and manually check out each file for editing as they go? Alternatively (and even better) is there a way to get VS to recognise that the files in a project are under source control, without having to add the project to source control also?
I know we could also take the tack of having every user check out for editing all files they might potentially want to edit ahead of time, then revert unmodified files before submitting their changes, is there a performance penalty in perforce in taking this approach?
In your case, I'd suggest not using the visual studio integration for Perforce.
You can either add Perforce commands to the Tools Menu, or try Nifty Perforce from Google:
http://code.google.com/p/niftyplugins/
One option is to use Perforce as if you were disconnected from the server and reconcile your changes later, rather than telling Perforce everything you do before you do it. (This is roughly equivalent to the workflow in CVS or Subversion.) You would synchronize your working copy, go off and develop, and then ask Perforce to figure out what you did while it wasn't watching.
Perforce has a nice document describing the process: Working Disconnected From The Perforce Server
One thing the document doesn't mention is the allwrite clientspec attribute, which marks all files in your working directory as writable instead of only the files you have checked out.
For the sake of completeness: There is a new tool for your wish called P4VS. I like it better that P4SCC which never worked for me as I wanted.