In instance 1 of Visual Studio I want to open the latest version of my source. In instance 2 of VS I want to open a previous version. How can I do this?
I tried opening two instances of VS and just pulling it, but since they both point to the same directory "C:\Source\ProjectName", I end up just overwriting one or the other.
Try creating another workspace and map it to a different file directory. Then have your original workspace open in VS #1 and the new workspace open in VS #2
Is there a reason you don't you just either branch or make copy of the solution to a separate folder on disk? That's what I would do (in fact, branching in TFS is specifically what we do for these sorts of situations).
[edit]
I'm assuming that the Compare feature is not what you're looking for? If so, there are fairly simple ways to enhance the default functionality there, such as using DiffMerge.
If you actually want to have two versions of the file open in two different VS instances, you will have to create an additional workspace that points to the same repository and use "get specific version" on the file you want.
Then you can have one instance of VS open with the latest version and the other instance open with the specific version.
You can learn how to create a new workspace here if you don't already know.
Related
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.
I am new to a company which uses TFS as a source manager. Currently when we make a new branch we create a copy of an old Build, then manually go in and edit all the workspace file paths and process definitions to reflect the new version(ie: if it was a copy of a 1.2.0 build, we go in and manually replace all the 1.2.0's with 1.3.0's)
Since we have ~70 folders and ~150 required processes to build, this gets rather tiring, time comsuming, and is error prone. I've read that there is an API for TFS you can use- Is there a custom script I could write to replace all the old version #'s with the new ones?
Also, under 'Workspace' its not too bad because you can copy it into notepad and do a 'ctrl+h' to replace it- it's really the processes that are killing it.
-Thank you, Kurtis
I highly suggest you look at installing TFS Power tools. It has a clone feature for build definitions that makes this very easy to do. I don't know why it isn't built in, but the power tools are really great.
Power tools for TFS 2010 -
http://visualstudiogallery.msdn.microsoft.com/c255a1e4-04ba-4f68-8f4e-cd473d6b971f
For 2010 you might need this one instead, but you should check both out - http://visualstudiogallery.msdn.microsoft.com/16bafc63-0f20-4cc3-8b67-4e25d150102c
I'm new to TFS so I'm trying to figure a couple of things out.
1) Are you allowed to reference the same code from multiple Team Projects?
2) How do you change the source control location for an existing team project?
The Server-Paths for each checked-in module has a format like $/TeamProject1/foo.cs.On the client-side, those files shall reside somewhere on the local HDD. The mapping between a $/TeamProject1/foo.cs & a local path C:/MyFiles/foo.cs is crafted by a TFS Workspace. Check here for an intro.To your questions:
1) Are you allowed to reference the same code from multiple Team Projects?On the server side: You can have branched, or simply commonly named source files, as in $/TeamProject1/foo.cs & $/TeamProject2/foo.cs, but those are surely different files.On the client side:Each locally mapped source control folder can only be correlated with one local path. In case you try to map both $/TeamProject1/foo.cs & $/TeamProject2/foo.cs into C:/MyFiles/foo.cs you 'll be denied the second time with something like that:In all, I think the answer to this question is a 'No'.2) How do you change the source control location for an existing team project?I suppose that you are trying to change the local mapping, for example from
$/TeamProject1 & C:\Folder\teamProject1 into
$/TeamProject1 & C:\AnotherFolder\TeamProject1
In order to do that navigate in VStudio to "File">"Source Control">"Workspaces.." then select your workspace & hit "Edit". There you can see the existing mappings and edit them.
Can you give an example of what you're trying to accomplish in question 1?
For question two, I'm assuming you're talking about where the code lives on a development desktop. For this, open visual studio and go to: File -> Source Control -> Workspaces. Then click Edit for your workspace. You can change the location here for each project you have mapped.
You can create a workspace that contains code from multiple team projects.
So, if I understand your first question correctly then yes you can do that. Technically the code will be in one Team Project but you can mix it into other Team Projects on your machine or build server using workspaces.
Are you familiar with workspaces yet?
The problem with renaming files is that if you want to take advantage of Visual Studio refactoring, you really need to do it from inside Visual Studio.
But most (not all*) version control system also want to be the ones doing the renaming.
One solution is to use integrated source control, but this is not always available, and in some cases is pretty clunky.
I'd personally be more comfortable using source control separately, outside of Visual Studio, but I'm not sure how to manage this question of file renames.
So, for those of you that use Visual Studio, which source control do you use? Do you use a VS integration (which one?) and otherwise, how do you resolve this renaming problem?
(* git is smart enough to work it out for itself)
I use SVN (TortiseSVN as the client) and use the Repair Move command from the commit dialog heavily. This allows me to rename the files within VS and resolve the rename when I'm ready to commit to keep version history.
As far as using the VS integration, like you, I find all VS integration clunky and do not use it.
mercurial usually prefers to do the renaming via hg rename however it can also detect renames from an outside source by using hg addremove -s 100 (or less than 100 if you want to match a rename with alterations) so clearly you can let VS do the rename and get mercurial to catchup with addremove.
We use SVN (TortoiseSVN to be exact), and i am always bothered with the renaming problem. The simplest solution i've found is to remove the files from the project, rename them via TSVN and add them back to the project. You have to manually update includes for renamed header files, but this is relatively easy using find&replace.
We use Team Foundation Server, and it works with no problems. I've also found that moving to using a fully integrated client has improved my workflow, as I don't need to flip between applications just to do trivial tasks.
We develop "Plastic SCM" and the Visual Studio Package supports move operations. But I see your point, I'm getting more and more comfortable with the idea of not having plugins/packages and then have the version control working behind the scenes and simply detecting what happened without having to be "plugged in" into the IDE. In fact we're working on it for next release...
Besides the above advice, for Visual Studio 2008 I found that after making all global changes to any file being renamed from within VS, including right clicking the file and renaming it, as well as a global search and replace for all strings, replacing the old file name with the new file name, you must, if the file is the initial startup file, right click and select it as "set as default page". Otherwise you'll may well get the "The resource cannot be found." error on runtime.
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.