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.
Related
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 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.
We’re on a closed network without Internet access so we’re currently using a file share as a NuGet repository. We do a lot of merging between a development branch and a main branch and occasionally setup a one-off branch for a hotfix or large functionality that will extend beyond our normal release cycles.
What we’ve found is that when we add a NuGet package to a project it puts a file path in the .csproj file for where the package is located. This works fine until we merge into another branch in TFS and then kick off a build. The builds do not pull down the same files from source control (keeping dev and main completely separate in that regards) so the package path is not found and the build fails.
We’ve come up with one solution we know will work but is utterly painful and one proposed solution that we need to investigate further. One solution is to put the packages folder into a common location that every build will include in its workspace and manually modify each .csproj file to point to that location for its packages.
The solution we need to investigate is using NuGet without committing packages to source control. What we need to determine is if NuGet.exe will create the folder structure needed by the .csproj file to find the package.
Are there better solutions to using NuGet in a branching environment that uses automated builds?
What you could do is create a local NuGet repository that is reachable by http:// that can be easily used in both branch situations. Checkout how to create a local NuGet repository here
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.
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.