Why using sharepoint as a sorce control is stupid idea:
Performance of sharepoint is much worse than any Source Control Tools for example Team Foundation Server or SVN
Sharepint doesn't allow to compare different historical versions of the same file
SharePoint dosen't allow for branching, merging and labeling.
Sharepoint doesn't link changes in set of files as a one change (this is very helpful if you want to track the changes)
As far as I know SP doesn't allow to have different versions of whole project in the same time.
SharePoint dosen't have customized gui to manage source control code.
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.
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.
Sharepoint is not a source control tool. There are many dozens of free and commercial tools that are designed for exactly this problem. Sharepoint is not one of them.
I realize these are points you've already stated in your post. I think that should be the end of the argument. If you have to go any further in defending against this horribly bad idea, I can't imagine what the rest of their processes are like.
但总的来说，我能想到的唯一好的原因是它没有与 IDE 集成，所以你将有很多工作使用它。想象一下，几个开发人员将他们的所有文件复制到共享点库，这会减慢他们的速度。
最后，它不够快，开发人员不会喜欢它（更重要的是因为增加了步骤）。
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).
它为二进制文件提供线性版本控制，有时这就是全部 你想要的。例如，如果您想对附加到的宏进行版本控制 MS doc 或 excel。
适合没有依赖项的二进制文件。
Using SharePoint as source version control:
Cons: - no support for de-duplication, every version is a folder is a full copy. - Unable to do full file set labeling for rollbacks - for example if you want to revert your product as a whole to specific point in time. - Files are not hashed, hashing is a modern technique for performance - for example git or mercurial only compare the hash values to determine if the file are identical which is very fast.
Pros using sharepoint as version control if yo already have the licensing.
it provides linear versioning for binaries, sometimes that's all what you want. for example if you want to version a macro attached to a MS doc or excel.
Surely though, a SharePoint library folder storing text files is preferable for using code within SharePoint. You wouldn't use bitbucket or confluence etc. for code that pulls in to a content editor webpart.
发布评论
评论（8）
为什么使用 sharepoint 作为源控件是愚蠢的想法：
Why using sharepoint as a sorce control is stupid idea:
许可成本...您可以以与 SP 相同的成本获得许多许多工具，但成本要低得多（即使他们对免费工具不屑一顾）。
此外，没有分支和/或合并。
使用 SP 进行源代码控制就像住在工厂里，因为它有 4 堵墙和一个屋顶。完全忽略了功能和意图。
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.
SP 的另一个问题是，如果有人删除了某个版本，SharePoint 不会保留删除者的完整历史记录（据我所知）。
可悲的是很多人，包括我们公司，都没有版本控制的概念。关键是他们需要接受有关配置管理或修订控制流程的重要性的教育。
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.
成本可能不是问题 - SP Foundation 是免费的。不过，这并不是一个好主意。
Cost is probably not an issue - SP Foundation is free. Still, not a good idea.
Sharepoint 不是源代码控制工具。有许多免费和商业工具专门针对这个问题而设计。 Sharepoint 不是其中之一。
我意识到这些是您已经在帖子中阐述的要点。我想争论到此应该结束了。如果你必须进一步防御这个可怕的坏主意，我无法想象他们的其余流程是什么样的。
Sharepoint is not a source control tool. There are many dozens of free and commercial tools that are designed for exactly this problem. Sharepoint is not one of them.
I realize these are points you've already stated in your post. I think that should be the end of the argument. If you have to go any further in defending against this horribly bad idea, I can't imagine what the rest of their processes are like.
SP 不与 IDE 集成，因此 CheckIN、CheckOut 将是手动的。
SP 没有办法创建分支（只能通过手动创建新文件夹并手动告诉开发人员使用新分支）。 （这将非常困难，具体取决于开发人员的数量）
SP 将每个更改视为独立于其余更改，因此无法查看时间线中的更改。之所以会这样，是因为 SP 源代码不是为“项目”源代码控制而设计的，而是为“文件”源代码控制而设计的。
SP 使用 varbinary(max) 将所有文件放在数据库上，这会增加 Sharepoint 数据库文件的大小，并且实际上它比放在磁盘上需要更多的空间。 （我并不是说 BLOB 是邪恶的，但是当大量使用时，它会让数据库维护变得很糟糕）
但总的来说，我能想到的唯一好的原因是它没有与 IDE 集成，所以你将有很多工作使用它。想象一下，几个开发人员将他们的所有文件复制到共享点库，这会减慢他们的速度。
最后，它不够快，开发人员不会喜欢它（更重要的是因为增加了步骤）。
SP Doesn't integrate with the IDE, so CheckIN,CheckOut will be manual.
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.
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).
使用 SharePoint 作为源版本控制：
缺点：
- 不支持重复数据删除，每个版本都是一个文件夹，都是一个完整的
复制。
- 无法为回滚做完整的文件集标记 - 例如，如果
您希望将整个产品恢复到特定时间点。
- 文件没有被散列，散列是一种现代的性能技术 -
例如 git 或 Mercurial 仅将哈希值与
确定文件是否相同，速度非常快。
优点
如果您已经拥有许可，请使用共享点作为版本控制。
它为二进制文件提供线性版本控制，有时这就是全部
你想要的。例如，如果您想对附加到的宏进行版本控制
MS doc 或 excel。
适合没有依赖项的二进制文件。
Using SharePoint as source version control:
Cons:
- no support for de-duplication, every version is a folder is a full
copy.
- Unable to do full file set labeling for rollbacks - for example if
you want to revert your product as a whole to specific point in time.
- Files are not hashed, hashing is a modern technique for performance -
for example git or mercurial only compare the hash values to
determine if the file are identical which is very fast.
Pros
using sharepoint as version control if yo already have the licensing.
it provides linear versioning for binaries, sometimes that's all what
you want. for example if you want to version a macro attached to a
MS doc or excel.
Good for binaries with no dependencies.
当然，存储文本文件的 SharePoint 库文件夹更适合在 SharePoint 中使用代码。对于拉入内容编辑器 Web 部件的代码，您不会使用 bitbucket 或 confluence 等。
Surely though, a SharePoint library folder storing text files is preferable for using code within SharePoint. You wouldn't use bitbucket or confluence etc. for code that pulls in to a content editor webpart.