He told me it's much more secure to use an SQL Sever based tool

Define (or get your boss to) "secure": security from data loss or access control?

The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access?

Using multiple Git repositories with limited users performing pulls from others into the designated "master" (from where releases will be taken) would offer much of the same control while helping to ensure code reviews are carried out.

(I have used TFS security to block some developers¹ from checking in. This was a reaction to the dire² quality of their code. Using TFS security allowed them to get the code, modify it but not to check in. Rather they had to submit a shelve set for me or another to review and check in (on their behalf via the command line). Most, especially initially, submissions were rejected.)

Update There might be a third way. TFS on the server and Git on the client. Depends on TFS2012 (just about to RTM). See Brian Harry's Announcing Git Integration with TFS.

¹Outsourcing anti-pattern: here are 6 great developers, lots of claims on their CVs, so they must be good, no need to interview/validate; they will now do most of the development.

² Think http://thedailywtf.com/ submission candidates...

He told me it's much more secure to use an SQL Sever based tool

Define (or get your boss to) "secure": security from data loss or access control?

The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access?

Using multiple Git repositories with limited users performing pulls from others into the designated "master" (from where releases will be taken) would offer much of the same control while helping to ensure code reviews are carried out.

(I have used TFS security to block some developers¹ from checking in. This was a reaction to the dire² quality of their code. Using TFS security allowed them to get the code, modify it but not to check in. Rather they had to submit a shelve set for me or another to review and check in (on their behalf via the command line). Most, especially initially, submissions were rejected.)

Update There might be a third way. TFS on the server and Git on the client. Depends on TFS2012 (just about to RTM). See Brian Harry's Announcing Git Integration with TFS.

¹Outsourcing anti-pattern: here are 6 great developers, lots of claims on their CVs, so they must be good, no need to interview/validate; they will now do most of the development.

² Think http://thedailywtf.com/ submission candidates...

He told me it's much more secure to use an SQL Sever based tool

Define (or get your boss to) "secure": security from data loss or access control?

The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access?

Using multiple Git repositories with limited users performing pulls from others into the designated "master" (from where releases will be taken) would offer much of the same control while helping to ensure code reviews are carried out.

(I have used TFS security to block some developers¹ from checking in. This was a reaction to the dire² quality of their code. Using TFS security allowed them to get the code, modify it but not to check in. Rather they had to submit a shelve set for me or another to review and check in (on their behalf via the command line). Most, especially initially, submissions were rejected.)

¹Outsourcing anti-pattern: here are 6 great developers, lots of claims on their CVs, so they must be good, no need to interview/validate; they will now do most of the development.

² Think http://thedailywtf.com/ submission candidates...

He told me it's much more secure to use an SQL Sever based tool

Define (or get your boss to) "secure": security from data loss or access control?

The latter certainly is easier in TFS (and I suspect that's what he/she wants). So the question is who would you block from access?

Using multiple Git repositories with limited users performing pulls from others into the designated "master" (from where releases will be taken) would offer much of the same control while helping to ensure code reviews are carried out.

(I have used TFS security to block some developers¹ from checking in. This was a reaction to the dire² quality of their code. Using TFS security allowed them to get the code, modify it but not to check in. Rather they had to submit a shelve set for me or another to review and check in (on their behalf via the command line). Most, especially initially, submissions were rejected.)

Update There might be a third way. TFS on the server and Git on the client. Depends on TFS2012 (just about to RTM). See Brian Harry's Announcing Git Integration with TFS.

¹Outsourcing anti-pattern: here are 6 great developers, lots of claims on their CVs, so they must be good, no need to interview/validate; they will now do most of the development.

² Think http://thedailywtf.com/ submission candidates...