Embrace, extend, extinguish is not new for MS, they have just upped the first parts in prep for the third. How people are so blind to this I dont know... Windows 10 is a perfect example of MS true goals.
For good reason. The battle for FOSS with the emphasis on F for Free (beer and speech) is still a very real one that will affect the future of technology as we know it. What amazes me is how much of hn has left that part of the 90s...
Which is why it's so important we embrace companies choosing to release FOSS. In order for the corporate world to push FOSS, they have to see that they're successful when they do it, and that it's possible for them to run businesses while contributing to and releasing their own work as FOSS.
TFS supports git repositories. TFVC is among the worst VCS I've used and really cannot be distinguished from CVS or SourceSafe in terms of usability or performance in my day to day experience (we have 3 TFS deployments, 2 TFVC only, one mixed TFVC and git repositories).
So, I'm cheering for .Net Core and I'm genuinely impressed by the MS SQL offering for Linux. This, on the other hand..
Also can confirm. Even with just 2 developers the conflict resolution is extremely poor and most of the time it just "resolves" it automatically, the wrong way, without telling you it even happened. VS integration has far less features than any third-party svn or git integration I've used. Getting it to ignore NuGet binaries is a pain. My current project is the first I've used TFVC on, it's only a few months old and there isn't really anything of value in the history. If the other guy agrees, I'm gonna move to git on the next slow day.
As someone who has never done meaningful Java development, I always find the project structure of Java codebases indecipherable. Why are there so many folders? I understand that namespaces depend on directory path, but it just seems like there is so much "stuff" here that I would have no idea where to even begin looking for an entry point or useful code snippet.
Almost all Java dev is done via full-featured IDEs which support advanced searching/finding, so simple file stucture isn't really considered a big priority.
Additionally, here they seem to have structured thing as a bunch of smaller projects, which seems pretty overkill but I'm not too familiar with it.
One reason there are so many sub-projects is that TEE has many build outputs: Eclipse plug-ins, a stand-alone application (I think this was removed), a command-line client with no graphical dependencies. These different products are built with different processes; Eclipse drives the Java compiler to build Eclipse plug-ins, but the command-line client is just Maven and javac, etc.
There's also some machine-generated code. TEE web service client classes are generated from TFS WSDL. That got stuck in its own project so the commit history was cleaner.
Being a large-ish, old-ish project that has proprietary roots, there are also a lot of compatibility and portability layers that a modern open source project could probably shed or replace with external dependencies.
Excuse me if I'm misremembering some details, it's been about 4 years since I worked on TEE.
14 comments
[ 4.7 ms ] story [ 52.5 ms ] threadTFS supports git repositories. TFVC is among the worst VCS I've used and really cannot be distinguished from CVS or SourceSafe in terms of usability or performance in my day to day experience (we have 3 TFS deployments, 2 TFVC only, one mixed TFVC and git repositories).
So, I'm cheering for .Net Core and I'm genuinely impressed by the MS SQL offering for Linux. This, on the other hand..
I can see how in some peoples' use cases it may be decent, but I don't understand why it would be anybodies first choice...or second...
Additionally, here they seem to have structured thing as a bunch of smaller projects, which seems pretty overkill but I'm not too familiar with it.
There's also some machine-generated code. TEE web service client classes are generated from TFS WSDL. That got stuck in its own project so the commit history was cleaner.
Being a large-ish, old-ish project that has proprietary roots, there are also a lot of compatibility and portability layers that a modern open source project could probably shed or replace with external dependencies.
Excuse me if I'm misremembering some details, it's been about 4 years since I worked on TEE.