Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We are looking for a version control tool. I personally think it's pretty cool to use Git. However, my boss recommends TFS. He told me it's much more secure to use an SQL Sever based tool, such as TFS and SourceAnywhere.

In addition, my boss also sent me a link.

My question is: Is it secure/strong enough to use Git or SVN for business usage?

share|improve this question
2  
git security is not granular, in terms of level of access or area of access. granting access to a shared repository can involve granting write access to the server’s file system. there are some 3rd party tools designed to provide easier and more granular access control for Git though. –  flysakura Aug 13 '12 at 8:01
12  
Is your boss going to be using the version control system picked? –  Thomas James Aug 13 '12 at 8:17
    
When you have a hammer, all problems are nail shaped. What happens to your repository when the database gets corrupted? –  Sardathrion Aug 13 '12 at 8:37
2  
@Sardathrion: You go back to the backup. In practice I cannot recall a database corruption not down to hardware failure. Data stores based on a bunch of files in folders accessed by multiple concurrent clients however is another matter. –  Richard Aug 13 '12 at 8:48
    
See my updated answer: You can have both. –  Richard Aug 15 '12 at 9:01
add comment

3 Answers

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 developers1 from checking in. This was a reaction to the dire2 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.


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

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

share|improve this answer
    
thank you. It seems git-tf is mainly designed for cross platform. –  LYQ Aug 16 '12 at 8:30
    
We do need the cross platform feature. But not quite sure about the advantage(s) of combining these two products. I'm also checking the tool from Dynamsoft. The website tells that it supports cross-platform itself. What do you think? –  LYQ Aug 16 '12 at 8:36
    
@LYQ Never heard of Dynamsoft so can't comment. The demo of Git-TF was on Windows, so not just about cross platform (which for pure TFS is covered by TFS Everywhere). Really just offering as an option which – for your situation – might offer the best of both worlds: manager happy with security and control of TFS, while you get the flexibility of Git locally (just the push process is a little different compared to a central Git repository). –  Richard Aug 16 '12 at 8:50
    
does git integration still give you all the features of git if you intentionally prevent the client from seeing half the repo? I doubt it, the git-TFS bridge will be a compromise. If you want git, go with git. If you want a central system, go with SVN. –  gbjbaanb Aug 16 '12 at 11:44
add comment

don't go with Git just because its "pretty cool", use it because it solves your problem in a way that fits with your workflow.

As for TFS... Martin Fowler had a little survey.

Anyway, you have to define "security" - do you want to protect the source from unauthorised users, or to put a read-only flag on some areas, or even prevent some people from looking at some areas. You can do this in SVN easily, use VisualSvn Server and you can apply r/rw security controls on any folder in the tree. TFS is the same. Git, on the other hand.. is not designed for this. Git works on the principle that all the source is 'copied' to each developer's workstation, so they get everything all the time. Its part of what makes git special - in that once you have all the source locally, you can merge and branch quickly and easily, but it means you do not get to put the corporate restrictions on it either.

The choice of back-end is meaningless. Use a file-based system, or a SQLServer based system.. its all the same, the level of security access depends on what the tool allows (and your admin policies on the back-end data, a SQLServer with a sa password of 'sa' or even unrestricted Windows auth would allow anyone access to the database).

share|improve this answer
3  
Damn, you have to suspect that there was some trolling of that survey going on if SourceSafe got a vote for "best in class". –  Carson63000 Aug 14 '12 at 3:46
    
Thank you, @gbjbaanb. "Security" means 1. the access control for the team members. For instance, some of our team members shouldn't have the share/branch permission. 2. preventing unauthorised users from accessing the source code. Can git have the data encyption feature? 3. One of the reasons we concerned about the file system and SQL Server based systems is that VSS is a file-based system. I know a lot of people hate VSS because of its frail database. Will Git and SVN have the same problem? –  LYQ Aug 15 '12 at 5:17
1  
The most common reason that I've seen companies switch to TFS is because of limitations in VSS (or Vault). They are good reasons to escape from VSS, but TFS is a poor code repository choice too. It's internal data structures make merging more complex for the user than it needs to be, and if you start thinking about code development in a change management style you will need the features of git / Hg / accurev style products –  Ptolemy Aug 15 '12 at 9:20
    
@Ptolemy I think you might have been reading a little too many anti-TFS pro-DVCS blogs. TFS merge is not as good as Git's. but it largely just works (and has been getting much better compared to the first version of TFS). Unclear what you mean by "change management style", but I've yet to find anything I cannot do in TFS. The right way in TFS is likely to be different (don't try and use TFS as if it were Git/Hg/..., use it as TFS). All this said, if you work for the boss, and the boss really wants to go in one direction sometimes you just need to get on with it. Consider who is paying you. –  Richard Aug 16 '12 at 8:54
    
I think the problem with TFS is not that its a particularly bad SCM, its that it comes with a load of "workflow" and "enterprise" features that your boss would love (on paper, and never have to use them himself) and devs hate. –  gbjbaanb Aug 16 '12 at 11:40
show 7 more comments

Open source projects use git to accept thousands of contributions from completely untrusted developers. Does no one in management ever stop to wonder how they accomplish that without constantly introducing malware? Or why the people with the most untrusted contributors actually prefer git?

If you can't trust your own developers with read access, you have a whole other set of problems. However, that's easy with git too. Just put limited access code on its own server. That's even easier to secure than permissions on a single server.

The next argument people make is, "Yeah, but with git you copy the entire history, not just the latest version." I have news for you. If you have read access to any VCS, you have enough access to create a git repository no one knows about. People do this all the time when management foists a subpar VCS on them. You don't know about it because it doesn't actually create the nightmare problems you fear it will.

There are plenty of reasons an enterprise might choose another VCS over git. Security isn't one of them. Probably the biggest reason is that git is more of one component of a VCS than an integrated system. You have to add your own authentication and authorization, integration with CI and bug tracking, etc. Also, git has a lot of power, but with that comes the need for locking down servers to prevent accidental use of that power, and more training. If you don't know about, or don't want, more advanced workflows, git looks like an unnecessarily complicated version of svn.

share|improve this answer
    
thanks for your comments. Would you please share more about "There are plenty of reasons an enterprise might choose another VCS over git. Security isn't one of them." –  LYQ Aug 15 '12 at 5:21
    
See my edits about potential reasons to choose another VCS. –  Karl Bielefeldt Aug 15 '12 at 13:38
    
Thank you @Karl –  LYQ Aug 17 '12 at 5:47
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.