Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Visual Studio and Team Foundation Server will have Git support

blogs.msdn.com

Post reply on HN
Print view View original

131–140 of 220 posts

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

#131

Post by pnathan »

jf wrote: post #62
pnathan wrote: post #51

Earlier quoted context omitted.

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

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

Okay, let's say that's your environment. How do you prevent Mole Manny (who is a legit developer in your organization) from pulling down all the files in his project (as he's entitled to do), and then copying it over to his $super_sneeky_storage_system?

We've talked a lot about this where I am and we've concluded that to ensure a super-tight environment we'd have to do a slew of really heinous lockdowns (epoxy usb ports for instance) which would likely not really do much against moles but slow down and anger legit users.

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

#132

Post by tedunangst »

encoderer wrote: post #89
tedunangst wrote: post #84

Earlier quoted context omitted.

It's called powershell.

No, not really. You cannot natively SSH from powershell. You need PuTTY. And Pageant. And... ugh.... A developer friendly terminal is definitely necessary.

Ok, so what we're really saying is, I want a vt100 emulator.

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

#133

Post by fusiongyro »

arrbee wrote: post #126
fusiongyro wrote: post #107

Earlier quoted context omitted.

It's more than the $0 it's given git.

Actually, MS has contributed significantly more than $20k worth of developer time to git / libgit2 over the past months, all open source GPL code

This only makes the $20K to Mercurial seem weirder, don't you think? It underscores my point that it's hard for large organizations to keep their official positions on things straight.

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

#134

Post by chiph »

pnathan wrote: post #51
jf wrote: 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 you write medical device or flight-control software, you have to have traceability all the way from requirements to the delivered binaries. With a central server & build system, that's much easier to do & also explain to federal inspectors.

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

#135

Post by jammycakes »

Moto7451 wrote: post #21
tobyjsullivan wrote: post #16

Earlier quoted context omitted.

I think you first have to ask why Microsoft is supporting git when Team Foundation is, itself, Microsoft's primary source control system. The answer is most likely because people use git. Lots of people use git - particularly the crowd Microsoft is actively struggling to appeal to which is the entrepreneurial/startup crowd. I've never used hg so I can't attest as to which is "better" but I really don't think that mat…

I've been an hg fan for a while and like it better (hg jives with my brain better and git occasionally throws weird problems at me) but quality wise I can't say there is much of a difference in my experience. That said, I have never met a single other person who uses hg. Not at work or hackathons. Most have never even seen an hg repository and some haven't even heard of it. Git definitely has "won" this "war".

The problem is that large swathes of the Git community have been treating the whole DVCS scene almost in Hunger Games terms -- there can be only one winner, and all the others must die.

For what it's worth, I've heard quite a lot of anecdotal evidence that Git is pretty contentious among many teams that adopt it. Git adoption is often driven by an aggressive few, against the wishes of their colleagues who can be quite unhappy about it. Case in point: Git has more "hates" on amplicate.com than Subversion and TFS put together -- and "hates" outnumber "loves" by something in the region of four to one. (http://amplicate.com/hate/git)

(For reference, Git and TFS have roughly similar market share in the enterprise at the moment, and Subversion is about twice as widely used as either of them. Source: itjobswatch.co.uk)

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

#137

Post by SideburnsOfDoom »

edwinnathaniel wrote: post #92
steeve wrote: post #76

Earlier quoted context omitted.

As a (now former) long time Window developer, and even though people like to bash on it, I still think VS (>2003) is the best god damn IDE I've ever used. And with .NET it leaves everyone in the dust, IMHO.

Dream on. Java ecosystems have left you guys by 10k miles.

In what way? What things are you comparing?

All I know is that the next version of Java will have features inspired by the last version of c# http://mail.openjdk.java.net/pipermail/lambda-dev/2011-Septe...

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

#139

Post by meaty »

jammycakes wrote: post #125
tucaz wrote: post #117

Earlier quoted context omitted.

I know nothing about nothing, but having that many projects under the same solution its the biggest clue that you are doing something very wrong. Even if you have a reason to have 40 projects in what should looks like one solution you can still create various solutions files with just the subset of projects you need. No one works on 40 projects at the same time.

It's sadly far too common for .NET developers to carve up their solutions into far more projects than are necessary. This can seriously slow down compilation times.

Actually if you are changing a dependency right at the bottom of the chain, it makes things much faster as each compilation unit (assembly) is less likely to be coupled to the changed code.

Large assemblies are the enemy of compilation time as you can't partially compile them (like you can with java individual classes).

Post reply on HN