Why shouldn't I use SharePoint for source control?

Question

I just started working at a company that doesn't have any kind of source control. I brought up that we might need to get some sort of source control going and one of my co-workers suggested that we use SharePoint. I think he likes the idea because we already use sharepoint he is a big SharePoint guy.

I came up with some reasons as to why we shouldn't do this.

• SharePoint isn't designed to be a source control tool for code.
• There are better (and still free) tools for the job
• You can't do automated deploys with sharepoint (to my knowledge)
• It won't integrate with any IDEs (to my knowledge)

Is there anything else I should include when i'm pleading my case?

Answer 1

Why using sharepoint as a sorce control is stupid idea:

1. Performance of sharepoint is much worse than any Source Control Tools for example Team Foundation Server or SVN
2. Sharepint doesn't allow to compare different historical versions of the same file
3. SharePoint dosen't allow for branching, merging and labeling.
4. Sharepoint doesn't link changes in set of files as a one change (this is very helpful if you want to track the changes)
5. As far as I know SP doesn't allow to have different versions of whole project in the same time.
6. SharePoint dosen't have customized gui to manage source control code.
7. Sharepoint doesn't allow to link requirements with code changes. For example TFS links work items with check ins. This is also very helpful if you want to track your business requirements and code changes.

Answer 2

Licensing Costs... You can get many many many tools that cost much less (even if they turn up their noses at free tools) for the same cost as SP.

Also, no branching and/or merging.

Using SP for source control is like living in a factory because it's got 4 walls and a roof. Totally ignores functionality and intent.

Answer 3

Another problem with SP, if there are versions being removed by someone, SharePoint doesn't keep the full history on who removed them (as far as I know).

The sad thing is a lot people, including our company, don't have the concept of revision control. The point is they need to be educated on how important it is to have a configuration management or revision control process.

Answer 4

Cost is probably not an issue - SP Foundation is free. Still, not a good idea.

Answer 5

SP Doesn't integrate with the IDE, so CheckIN,CheckOut will be manual.

• By the way GIT doesn't integrate with the majority of IDE's and it is still one good SC tool.

SP Doesn't have a way to create branch's (only by manually creating a new folder and manually telling the devs to use the new Branch). (this will be pretty hard depending on the number of devs)

SP treats every change as independent of the rest, so no way to look at changes in a timeline. This is like this because SP source is not made for "project" source control, its made for "file" source control.

• This is a downsize.

SP places all files on database using varbinary(max) this increase the Sharepoint Database file size, and it actually takes a little more space than what it would if it was on disk. (I'm not saying BLOB is evil, but when used a lot it makes DB maintenance HELL)

But overall the only good reason i can think off is that it doesn't integrate with the IDE, so you will have a lot of work to use it. Imagine several developers copying all of their files to a sharepoint Library, that would slow them down.

And Last its not fast enough devs won't like it (even more because of the added steps).