7

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?

Improve this question
5
  • 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
    Commented Aug 13, 2012 at 8:01
  • 15
    Is your boss going to be using the version control system picked?
    – Thomas James
    Commented Aug 13, 2012 at 8:17
  • When you have a hammer, all problems are nail shaped. What happens to your repository when the database gets corrupted?
    – Sardathrion - against SE abuse
    Commented Aug 13, 2012 at 8:37
  • 4
    @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
    Commented Aug 13, 2012 at 8:48
  • See my updated answer: You can have both.
    – Richard
    Commented Aug 15, 2012 at 9:01

3 Answers 3

Reset to default
10

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

Improve this answer
12
  • 5
    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
    Commented Aug 14, 2012 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
    Commented Aug 15, 2012 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
    – Michael Shaw
    Commented Aug 15, 2012 at 9:20
  • 1
    @LYQ : no, only VSS has the direct clients accessing the network file system problem. SVN and Git both use a server process to write the data safely using a transaction approach.
    – gbjbaanb
    Commented Aug 16, 2012 at 11:42
  • 1
    @Ptolemy I can't see how one would do that in Git either. The same diff applied into different files (because they're in a separate branch other changes have also been applied in that branch) is going to give a different id. There is no handle on the change, only on the results of the change: which is going to be different. (If you're two branches are the same – eg. different remote repositories – then you are just saying TFS isn't a DVCS and only in a DVCS can you do "real" change management. This is clearly not a generally held view: CM pre-dates DVCSs for a start.)
    – Richard
    Commented Dec 8, 2012 at 12:49
7

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

Improve this answer
4
  • thank you. It seems git-tf is mainly designed for cross platform.
    – LYQ
    Commented Aug 16, 2012 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
    Commented Aug 16, 2012 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
    Commented Aug 16, 2012 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
    Commented Aug 16, 2012 at 11:44
3

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.

Improve this answer
2
  • 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
    Commented Aug 15, 2012 at 5:21
  • 1
    See my edits about potential reasons to choose another VCS.
    – Karl Bielefeldt
    Commented Aug 15, 2012 at 13:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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