Live data from Hacker News

Visual Studio and Team Foundation Server will have Git support

blogs.msdn.com

61–70 of 220 posts

Re: Visual Studio and Team Foundation Server will have Git support

#61
post #20

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…

Either the pain is worth $400 to avoid, or it's not... seems simple enough to me! (Same for 'PIX for Direct3D 11.1')

Re: Visual Studio and Team Foundation Server will have Git support

#62
post #51
post #14

Earlier 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?

If I remember correctly, certain regulatory environments require that an audit log be kept of who saw which file and when.

Re: Visual Studio and Team Foundation Server will have Git support

#63
post #15

Earlier 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.

[deleted]

Re: Visual Studio and Team Foundation Server will have Git support

#64
post #20

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…

Any company that sells software on Windows can surely afford the professional license.

Re: Visual Studio and Team Foundation Server will have Git support

#65
post #51
post #14

Earlier 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?

Some code like encryption algorithms cannot leave the United States by law (if developed by a US company/Citizen).

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

#66
post #15

Earlier 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.

For me, this is primarily a reflection of the quality of service and community on Github rather than any quality intrinsic to git. I prefer mercurial to git, but find myself using git significantly more as virtually every dependancy in the apps I build lives on github.

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

#67
post #51
post #14

Earlier 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?

I've worked on things like poker machine software.

Pieces like the random number algorithm for that stuff is tightly controlled.

Re: Visual Studio and Team Foundation Server will have Git support

#68
post #39

Earlier 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. :-(

.dbml files are a pain to merge because on any change, that element is moved to the bottom. To avoid other people smashing my changes I manually move it back to where it was before checking in, so the diff is only one or two lines. No one else on the team does this though, so they still run into problems.

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

#69

This 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…

Did you actually clone the branch or did you manually set up the remote and branch?

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

#70
post #51
post #14

Earlier 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?

I can speak from my own experience there are times where depending on funding, portions of a project must be developed by U.S. citizens... but the bigger project can have parts developed over seas. Depending on funding and the project.
Post reply on HN