I did a stupid thing and branched my project on my local disk instead of doing it on the TFS. So now I have two projects on my disk: the old one which has TFS bindings and the new, which doesn't. I want to merge those changes back into the TFS project. How would I go about doing that? I can't do Compare because my local branch has no TFS bindings. There should be some way to compare the differences between the two projects locally and then meld the differences into the old project and check-in, but I can't find an easy way of doing that. Any other solutions?
How about using a 3rd party tool to compare and merge.
You can always do a get on the source (c:\tfs\solution) and compare it with the local project (c:\myLocalSolution).
Check out the entire tfs solution for edit before merging your local to the tfs.
Related
I have been struggling with what (at least in my mind) should be simple:
I have two projects, the "MainProgram" and a "SubLibrary". Both were created with a Git Repository using the new Visual Studio 2012 Git support.
Both repositories work fine independently.
However when I "Add Existing Project"/SubLibrary to my MainProgram Solution, SubLibrary is not being "git-monitored" by Visual Studio at all - no overlaid status icons in Solution Explorer etc. - its just as if that project was not under source-control.
Through some research, I added a git submodule to the MainProgram repo, added the cloned version of SubLibrary project to the solution and .. the git-icons in Solution Explorer appeared!! ... but my joy was short-lived ..... No History, the status of changed files did not show in Solution Explorer. The changes were however picked up by TortoiseGit from within File Explorer.
The .gitmodules file looked OK (but as you can gather I am NO git guru!) .....
Surely it must be possible to have version control over multiple projects/repos within a single solution!
I would be very greatful if anyone could point me in the right direction!
In Git it is indeed usual to have smaller repositories. A typical repository will contain a single project while TFS and Subversion tend to have multiple projects in a single repository.
That will lead to the situation you described. Currently as far as I can see there is no git multi-repository support within Visual Studio (and TFS). It is simply not possible to have a single solution with multiple projects while each project resides in its own Git repository.
What I've done in the past:
I created a directory that served as the root
In that directory create a subdirectory for each individual project
Clone each git repository in its respective subdirectory
In a project use a file reference with a relative path to add references
(optional) create a single MSBuild file that builds all the solutions in its correct order. This way you can create a build using multiple Git repositories.
You won't have a single solution this way, but you will be able to track your changes in each individual repository.
Hope this helps you.
I want to branch my solutions to a different TFS server with TFS 2010.
Is there any way to do this?
You cannot branch between servers (or Project Collections) in TFS.
Do you need to do a one off move to a new server? In that case, restoring a backup of your current server to the new server and deleting the Team Projects you don't need might be a solution. If you need to be able to "merge" the code back to the original server at some point you could look at the TFS Integration Tools. This will allow you to move the code over to a new server and also keep the code synchronised.
However there are limitations with the toolkit, see the link for more information.
Why do you need to use a new server? Why won't a new branch in the current Team Project suffice?
I have a visual studio 2010 project under mercurial. I use mercurial either via command line or TortoiseHG. I want to work on a new feature, so I clone the repo. But now I am confused, am I supposed to import an entire new project into VS2010 just to work on this feature? I tried importing the VS Solution that was cloned, but got lots of build errors from dependencies cannot be found errors, which I assume is because I am trying to load this cloned Solution just like the original Solution and some paths are wrong (no idea where though).
How are you supposed to use mercurial and VS2010?
Cloning produces an exact copy of the original repository.
The clone should work exactly the same way as the original repository, so you open your cloned solution exactly the same way as the original one.
If you get build errors in the cloned solution but not in the original one, there are probably some dependencies (=3rd party assemblies that your application needs to work properly) which exist in the original solution, but weren't committed to the repository.
So, when you clone the repository, the referenced files are missing in the clone...so the clone won't work.
Source control works the best way if you check in the complete solution, including all dependencies:
Make a "Libs" folder somewhere in your solution, put all your dependencies inside, reference those files from your solution and commit the whole "Libs" folder to the repository.
If you do it this way, you can clone the repository from a different machine and open the solution, without worrying about any dependencies...it just works.
It sounds like your root problem is that you're adding references using full paths rather than relative paths. You'll need to rectify that before branching is going to be easy for you. I usually make a "References" folder that is on the same folder level as the .sln file, but one level up from the individual projects, then branch the whole thing.
Example Folder Structure
MySolution
MySolution.sln
References
MyProject1
MyProject2
As for VS integration, I use TortoiseHG combined with VisualHG, it works great.
There is also Mercurial Toolbar
Other tools
This may or may not be related, but I've had to load hotfix KB2286556 in order to get rid of the "Unable to update project dependencies" error from VS2010 when building a fresh checkout of our code. It seems this only happens to setup and deployment projects when compilation is invoked from the command line (such as in our build system), but when it happens it's a very frustrating issue to find the solution for.
Also, VisualHg is a good way to track and invoke versioning from within Visual Studio.
While VisualHG still proves to be a wonderful tool after so many years, I would also suggest HgSccPackage as a very viable alternative for all Visual Studio versions (up to VS2015).
PROS: Stand-alone package (TortoiseHg is not required).
CONS: Doesn't have all the handy features of TortoiseHg such as Git support (which I find incredibly handy to handle GitHub-hosted projects) and Mercurial Keyring.
Both of them are freeware and can be installed through the Visual Studio GUI (Tools > Extensions and Updates...).
For a more extensive comparison between them you can also read this post on my blog.
Imagine a solution in Visual Studio 2008 that consists of three projects. Two of them are file-system wise located under the solution home directory and a third one that has been added via Add Existing project from a location outside the solution.
The first two projects are part of the git repository covering the solution directory while the third one has its own git repository since it is simply a utility library shared accross several solutions.
My problem is that I can commit changes to git in Visual Studio by selecting a file or folder in one of the projects but I am unable to commit all changes to all projects by selecting the Root Node in the Solution Explorer. I am fully aware that this would imply a multi-repo commit performed by Git Extensions. But still does anyone know how to do this or is this simply not possible?
This is not possible since they are separated repositories.
The best solution that is available, is to add the second repository as a submodule to the first repository. This will not make committing any easier, but it will allow you checkout an old revision for both repositories, without manually having to find the corresponding commit in the second repository.
Our dev team is small (3 developers) and windows based.
I'm looking for a source control that can do the following:
Check out files for editing and warn others that file is used
Check in files and merge if they have changed
Split baselines for release versions and merge baselines if needed
Visual Studio integration
Can work over WAN
Thanks.
SW
Team Foundation Server fits all of those.
SVN would be great, as long as you use locking (normally the server has no idea what clients are doing by default)
Perforce might be a nice one to look at which does this more by default.
Both have VS integration, SVN especially.
SVN, provided that you explicitly lock the files. This is not by default, but you can easily lock the file via SVN commands or via TortoiseSVN.
VisualSVN provides the Visual Studio integration.
If you want good Visual Studio Integration, then check out Microsoft Team System. You didn't specify if you wanted free or commercial or how critical Visual Studio intergration was.
git will do almost all of it. Not sure about integrating it with Visual Studio though. there might be a plugin for that.
Reasons:
No central server needed. If you want one, you can have one, but it's not necessary
You can push/pull changes to the others at will.
Each of you can have your own local branches, and push only the ones you need to
each other. Branching/merging is easy enough to do branch-per-task. Then push just that task to a co-worker if needed.
Unlike SVN, only one directory is needed for git, in the top level of the directory structure.
git stash rocks for when you have changes in your current branch, and need to switch to another for a while. This is one of those things you don't miss until you don't have.
Merges are awesome.