Live data from Hacker News

Visual Studio and Team Foundation Server will have Git support

blogs.msdn.com

171–180 of 220 posts

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

#171
post #119

Earlier quoted context omitted.

Yes, agreed (having worked on middlish-big projects with maybe 40 VS projects for each solution, 45+ minute re-compile times (not from scratch) on the latest gen CPUs, etc) with several hundred million LoC but believe me, if you think that's bad, you don't want to see Eclipse/NetBeans/XCode/etc. with a project a thousandth of that size.

Slightly curious, what kind of projects were you working on that are "several hundred million LoC"... wouldn't 45-minutes be reasonable for that many lines of code? I ask because I've never even come close to touching a project with that many SLOC and I was also under the impression that most modern operating systems are barely fitting into 100million+ LoC category, correct? This is your chance to redefine my perspec…

A lot of the code may be automatically generated.

Some C# developers use T4 to generate data access code, for instance. This can amount to several hundred thousand lines of code for a moderately sized database. If there are several large databases being accessed, like is often the case in reality, then I could easily see there being millions of lines of automatically generated code in a single project.

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

#172
post #166

Earlier quoted context omitted.

We have a solution with more than 80 C# projects, and visual studio 2010/2012 handles it fine on modest hardware. I usually hit shift+F6 to build just the current project when I'm iterating on some change. This builds very fast because our individual libraries are small. It doesn't really feel "wrong".

Unless u have a very good reason to deploy and distribute 80 different DLLs it should feel wrong. Many people think that In order to have a well layered and decoupled application you need to breakup every single piece in a separate project and that makes no sense. Thats what folders and namespaces are for.

For C#, maybe (not enough experience, but I would be surprised if what you say is a good practice).

For C / C++: You do that with static libraries, not shared libraries, and that's the only sane way to work: Have all library projects part of your main workspace, so you can easily debug and fix stuff in them, yet manage them independently.

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

#174

Earlier quoted context omitted.

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

C# tools and libraries have been inspired by Java since the inception.

I'll give C# a +1 for lambda/functional feature but the rest does not equal +1.

MSBuild -> Ant

NuGET -> Ivy

DoesNotExist -> Maven (don't forget to count maven plugins).

NHibernate, Log4Net, etc -> inspired by its Java counterpart.

How about sane deployment/packaging system? WAR, JAR, EAR push to App Server (tomcat, glassfish, etc). Not so easy with IIS.

I argue that Java open source library is far richer than .NET (no hadoop, no hbase, no cassandra, nor GWT)

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

#175

Earlier quoted context omitted.

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

I'm curious, what Java IDE is 10K miles ahead of Visual Studio 2012/C# in your experience? Have you recently used VS with C#?

Have you ever used Eclipse with various Maven plugin? (and any source control plugins: SVN, GIT, Mercurial, etc).

Thing is, Eclipse/IntelliJ plugin ecosystems are far richer and waaay more cost effective (and powerful) than VS.NET plugin ecosystems.

I know I keep pointing to Maven but Maven alone is a huge reason why .NET is left to dust.

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

#176
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. :-(

The developer division has used TFS for over four years now. You can read about the scale and topology at http://blogs.msdn.com/b/buckh/archive/2012/06/08/developer-d.... Ryan was being nice when talking about the transition. We put the division through hell for a while (fall of 2008 until spring 2009), but the result was an amazingly scalable centralized version control system. Now with our full, native support for git in VS, on the server (just on the service http://tfs.visualstudio.com for right now), and joining the community to help build libgit2 (check out the committers page), TFS also supports the best DVCS.

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

#179
post #76
post #49

Rock on, Microsoft — this is great news for Windows developers. As much as the open source community (of which I am a part) loves to rag on Microsoft, they seem to have recognized the threat of platforms moving off of Windows (Steam, iPads, Android, ...) and are taking reasonable steps to encourage development for Windows (make the developer experience better). This — a reasonable response to a potential threat — is…

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.

I change one line of C# in a unit test, and ask VS to run the unit test.

It then spends 30 seconds building.

This kills TDD and many other ways of exploratory development.

This is not the case in any Java or Python IDE.

Post reply on HN