It will be really nice to see a proper Git client for Windows especially if it means Windows is also getting a proper SSH.
Visual Studio and Team Foundation Server will have Git support
31–40 of 220 posts
Re: Visual Studio and Team Foundation Server will have Git support
#32Git doesn't transplant from the UNIX ecosystem very well. It's why the only options for Git in Windows so far have been as part of a UNIX interop solution like msys, cygwin, interix, etc. It will be really nice to see a proper Git client for Windows especially if it means Windows is also getting a proper SSH.
Only downside is you have to convert scripts you find online from bash -> powershell
Re: Visual Studio and Team Foundation Server will have Git support
#33Apparently libgit2, which they're using for this has the license: libgit2 is under GPL2 with linking exemption. This means you can link to the library with any program, commercial, open source or other. However, you cannot modify libgit2 and distribute it without supplying the source. That sounds nice to me, but I'm not sure how that differs from the standard LGPLv2.
LGPL requires that any distribution be able to replace the LGPL component with a modified version. If you use it as a shared library (er, DLL in this case I guess) you get that for free. But if, for example, you want to link a LGPL library statically you need to provide a static library containing the rest of your program in a linkable form. The point is to allow the user the ability to exercise their right to modify…
Re: Visual Studio and Team Foundation Server will have Git support
#34Earlier quoted context omitted.
While there are a lot of compelling reasons to use a distributed version control tool, there are also compelling reasons to use a centralized system. Having a lot of giant files (game resources are the canonical example) suits a checkout/edit/checkin system much better than a system that scans the disk like a edit/merge/commit system or a DVCS. These sorts of repositories exist within Microsoft (and DevDiv) itself. F…
A couple of other reasons to use centralized version control: 1: You are a Fortune 100 company and need to have access control on your codebase (so you can give contractors access to only a few files for example) 2: The code you are writing is subject to regulatory control.
you can still use git-tfs to use tfs like you would use svn. you can also just copy the file to another folder and suddenly everything is good. or you use time machine or another other backup mechanism.
Do i miss something magic that tfs does, that I don't understand?
Re: Visual Studio and Team Foundation Server will have Git support
#35At work we still use TFS2008 and there doesn't seem to be any way to migrate the source with history except for upgrading the whole TFS installation to a newer TFS. So when TFS2012 is up and running on another machine we are going to move a snapshot.
Contrast this to the freedom and "decentrialessness" when using git.
MS must seriously use their own products more.
Re: Visual Studio and Team Foundation Server will have Git support
#36This is great news! At work we still use TFS2008 and there doesn't seem to be any way to migrate the source with history except for upgrading the whole TFS installation to a newer TFS. So when TFS2012 is up and running on another machine we are going to move a snapshot. Contrast this to the freedom and "decentrialessness" when using git. MS must seriously use their own products more.
Re: Visual Studio and Team Foundation Server will have Git support
#37Earlier quoted context omitted.
How are ATL and MFC crucial in 2013?
If you wish to make a Visual Studio style application, there are few quicker options than MFC. You get a lot of functionality just with the wizard generated app.
(I've not used VC++ since version 5 or 6)
Re: Visual Studio and Team Foundation Server will have Git support
#38Earlier quoted context omitted.
For compiling legacy code. Found a library that does exactly what you need, but it uses ATL somewhere in its guts? Sorry, won't compile with Visual Studio Express.
VS Express isn't exactly aimed at supporting legacy code for you. The Express products are free, light(er)weight and don't support everything the other editions do. You should have known this going into this. There are however other library downloads from Microsoft that may make both MFC and ATL libraries available to the Express editions.
I'm not saying that Microsoft should actively support new development in MFC/ATL. All I'm saying is that they shouldn't delete ATL/MFC from the Express SKU.
It's true that it's still possible to get ATL/MFC in the free Platform SDKs for (much) older versions of Windows, but finding and installing it and integrating it with Visual Studio is a royal pain, and Microsoft won't tell you how to do it (or even that it's possible). And there's no way to get PIX for Direct3D 11.1 without paying $400+.
Re: Visual Studio and Team Foundation Server will have Git support
#39This is great news! At work we still use TFS2008 and there doesn't seem to be any way to migrate the source with history except for upgrading the whole TFS installation to a newer TFS. So when TFS2012 is up and running on another machine we are going to move a snapshot. Contrast this to the freedom and "decentrialessness" when using git. MS must seriously use their own products more.
MS uses a custom internal-only fork of Perforce. They've used it for quite some time now. It was considered a "competitive advantage" so they used that while Visual Source Safe (lol) and TFS were used by the outside world.
Edit: I can't reply to your comment for some reason. If they do use their own tools, how come it's so easy to get insane merging problems on so many of the xml files in use by a VS project? Especially the .dbml files, but also the project files. :-(
Re: Visual Studio and Team Foundation Server will have Git support
#40Earlier quoted context omitted.
A couple of other reasons to use centralized version control: 1: You are a Fortune 100 company and need to have access control on your codebase (so you can give contractors access to only a few files for example) 2: The code you are writing is subject to regulatory control.
sorry, help me understand here. How does something who's only method of control is tied to the ide you use keeping any control over the source code? you can still use git-tfs to use tfs like you would use svn. you can also just copy the file to another folder and suddenly everything is good. or you use time machine or another other backup mechanism. Do i miss something magic that tfs does, that I don't understand?
For example: One could tell the TFS server "Deny Contractor-X access to all files, except for files A, B, and C". I assume that this would only allow Contractor-X to access files A, B, and C. Even if they were using git-tfs.