While there are a lot of compelling reasons to use a distributed version control tool, there are also compelling reasons to use a centralized system. Having a lot of giant files (game resources are the canonical example) suits a checkout/edit/checkin system much better than a system that scans the disk like a edit/merge/commit system or a DVCS. These sorts of repositories exist within Microsoft (and DevDiv) itself. For that reason alone, TFVC won't be going anywhere anytime soon.

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.

Interesting you should mention that. We have our code on a corporate SVN server but I used git (via git svn) to create a mirror for some offshore developers outside the export control bubble. Git allowed me to exclude a set of files very easily. Not an argument pro or con either system, just saying.

This is why we use svn still.

Also, its easier for developers not to fuck it up royally.

sorry, help me understand here. How does something who's only method of control is tied to the ide you use keeping any control over the source code?

you can still use git-tfs to use tfs like you would use svn. you can also just copy the file to another folder and suddenly everything is good. or you use time machine or another other backup mechanism.

Do i miss something magic that tfs does, that I don't understand?

I can't speak for TFS, so maybe they do something daft, but it's usual that when you get latest from the server you simply won't get the files you aren't allowed to. You won't even see them. It's access control at a finer grain than the repository level, applied on the server side.

(with git always giving you the whole repository, there's not much you could do with git, but but many systems don't do that.)

I've never used TFS but my understanding is that TFS server allows you to configure it to only give a specific person access to a specific set of files.

For example: One could tell the TFS server "Deny Contractor-X access to all files, except for files A, B, and C". I assume that this would only allow Contractor-X to access files A, B, and C. Even if they were using git-tfs.

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

Really? The only places I've run into regulatory requirements for audit logs of seeing data is when the data itself is sensitive government data or is legally protected personal data; outside of national security, those aren't the kind of things that generally apply to code (and in the national security space, I'd imagine that you'd need more comprehensive monitoring of your systems, desktop or server, such that using centralized VCS for the purpose would be redundant [alone, centralized VCS for that purpose has holes big enough to drive a truck through, since it can't monitor who sees information once it is checked out, only who checked it out].)

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.

I've worked on things like poker machine software.

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

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.

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.

If your encryption key generation security depends on people not knowing how you generate keys, then it's totally busted.

Ah, but the question isn't Is this a good idea? but Is this legally required?

Not always the same.

It may not depend on it, but it will improve it by some small margin most of the time.

Centralized version control doesn't have any advantage over distributed version control for either of those scenarios. Particularly, it doesn't give you any more control over where the code goes after someone with authorized read access to the repository makes their own copy of it.

For that, you need comprehensive monitoring on every system from which the repository can be accessed that tracks what is done, and once you have that, it doesn't really matter what you do for VCS for that kind of monitoring.

One think that I've been impressed with is that changes you make from the command line are reflected instantly in the GUI. I like to change branches from PowerShell with posh-git. I'm using the GUI and command line interchangeably.

(Disclaimer: I work for MSFT but not in the git/vs group)

Glad you like it! (I work for MSFT and I tested this feature).

This is one feature that Eclipse don't have since you have to refresh everytime there is changes outside the IDE.

Every time someone says VS blows Eclipse I wonder what VS have that Eclipse don't. When I dabbled C# few years ago, I find the textual support for refactoring and such are much lacking in VS IMO. I haven't tried Resharper though.

My brother applaud VS for its WYSIWYG, but you rarely do that when you program in Java.

Resharper adds so much values to VS, that's it's hard for me to work without it. I've been using resharper for about a year, and it's simply amazing. My productivity has gone through the roof (I've been using VS since 2003). Alt+Enter gives you the magic.

Currently working in VS and Eclipse at my current gig. One thing that I definitely miss when working in Eclipse is the ability to move the instruction pointer around at my own discretion. Though, admittedly, I'm unsure if this is a limitation of the languages more so than the IDE. /digression

> This is one feature that Eclipse don't have since you have to refresh everytime there is changes outside the IDE.

That used to annoy me a lot. But isn't there a setting that makes Eclipse scan for changes on the file system now? I don't remember what it's called.

God I wish emacs would do that with magit, though maybe there is some elisp out there that would aide me. Too lazy to look.

Put

   '(global-auto-revert-mode t)

In the "custom-set-variables" section of your .emacs, and it will automatically reload any file open in emacs that changes on disk (excepting files with unsaved changes). While it's a little slow doing the actual reloads under Cygwin, it's blinding fast on Linux. Works a charm with egg, haven't tried magit.

File system notifications are proprietary to each OS, so you may not find anything great.

I'd never imagine a git UI that totally replaces the CLI (/git bash), but that doesn't mean you can't benefit from IDE integration alongside it.

MS's enterprise customers already on TFVC would be mighty ticked if they outright killed or deprecated it; wouldn't be terribly surprised if development slowed down though.

Considering Visual SourceSafe's extended support runs through 2017, I think it's safe to say TFVC will be around and supported for quite a while yet.