Earlier quoted context omitted.
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 know that Express isn't "aimed" at supporting legacy code. What I'm saying is, that's a bad product decision by Microsoft at a crucial time when they can't afford to alienate any developer who's still interested in developing for their platforms. 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…
Visual Studio and Team Foundation Server will have Git support
61–70 of 220 posts
Re: Visual Studio and Team Foundation Server will have Git support
#62Earlier 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.
> 2: The code your are writing is subject to regulatory control. Can you expand on what, precisely, you mean by that?
Re: Visual Studio and Team Foundation Server will have Git support
#63Earlier quoted context omitted.
The article seems pretty clear on that. "When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS."
It's worrying that Git is becoming the OSS "monopoly" in the DVCS space.
Re: Visual Studio and Team Foundation Server will have Git support
#64Earlier quoted context omitted.
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 know that Express isn't "aimed" at supporting legacy code. What I'm saying is, that's a bad product decision by Microsoft at a crucial time when they can't afford to alienate any developer who's still interested in developing for their platforms. 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…
Re: Visual Studio and Team Foundation Server will have Git support
#65Earlier 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.
> 2: The code your are writing is subject to regulatory control. Can you expand on what, precisely, you mean by that?
Another example might be Credit Card Processing software, you don't want a lot of people knowing how you generate your encryption keys.
Re: Visual Studio and Team Foundation Server will have Git support
#66Earlier quoted context omitted.
The article seems pretty clear on that. "When we made the decision that we were going to take the DVCS plunge, we looked at many options. Should we build something? Buy something? Adopt OSS? We looked at Git, Mercurial and others. It didn’t take long to realize that Git was quickly taking over the DVCS space and, in fact, is virtually synonymous with DVCS."
It's worrying that Git is becoming the OSS "monopoly" in the DVCS space.
I do think however that there are lots of teams, particularly in enterprise, that are quietly and happily using mercurial.
Re: Visual Studio and Team Foundation Server will have Git support
#67Earlier 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.
> 2: The code your are writing is subject to regulatory control. Can you expand on what, precisely, you mean by that?
Pieces like the random number algorithm for that stuff is tightly controlled.
Re: Visual Studio and Team Foundation Server will have Git support
#68Earlier quoted context omitted.
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.
I know, and it shows. This is exactly what the VS/TFS/Azure team must stop doing. 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. :-(
I tried to find where the 'Startups for the Rest of Us' AuditShark guy (Mike?) talks about writing a tool so that his outsourced devs wouldn't have to deal with it, but it would take me too long to find. He doesn't seem like the type to believe in open sourcing anything but I wish he would consider it.
Re: Visual Studio and Team Foundation Server will have Git support
#69This seems alright, but it definitely feels incomplete. I tried it out with one of my github projects, and the setup wasn't impressive at all. First, it didn't automatically detect that there was a 'GitHub' remote. My first guess was that I needed to call it 'origin', but that didn't fix it. Instead, I needed to go into the command line and specify the master branch's upstream branch like so: "git branch --set-upstre…
I ask because a clone sets the upstream automatically, and inferring the remote from the branch's upstream is the correct behaviour. You can also use the -u flag in push/pull to set this.
Re: Visual Studio and Team Foundation Server will have Git support
#70Earlier 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.
> 2: The code your are writing is subject to regulatory control. Can you expand on what, precisely, you mean by that?