为什么不使用SharePoint进行源代码管理?

为什么使用sharepoint作为排序控件是愚蠢的想法:

1. sharepoint的性能比任何源代码管理工具(例如Team Foundation Server或SVN)都差得多
2. Sharepint不允许比较同一文件的不同历史版本
3. SharePoint不允许分支、合并和标记。
4. Sharepoint不会将文件集中的更改链接为一个更改(如果要跟踪更改,这非常有用)
5. 据我所知,SP不允许同时拥有整个项目的不同版本。
6. SharePoint没有自定义的gui来管理源代码。
7. Sharepoint不允许将需求与代码更改相链接。例如,TFS使用签入链接工作项。如果您希望跟踪业务需求和代码更改,这也非常有用。

许可费用。。。你可以用和SP一样的价格买到许多便宜得多的工具(即使他们对免费工具嗤之以鼻)。

此外,没有分支和/或合并。

使用SP进行源代码控制就像生活在工厂里一样,因为它有4面墙和一个屋顶。完全忽略功能和意图。

SP的另一个问题是,如果有人删除了版本,SharePoint不会保留删除它们的人的完整历史记录(据我所知)。

可悲的是很多人,包括我们公司,都没有版本控制的概念。关键是他们需要接受教育,了解配置管理或修订控制过程的重要性。

成本可能不是问题-SP基金会是免费的。不过,这不是个好主意。

SP与IDE不集成,因此签入、签出将是手动的。

• 顺便说一下,GIT没有与大多数IDE集成,它仍然是一个很好的SC工具。

SP没有创建分支的方法(仅通过手动创建新文件夹并手动告诉开发人员使用新分支)。(这将非常困难,取决于开发人员的数量)

SP将每一个变更都视为独立于其他变更,因此无法查看时间线中的变更。这是因为SP source不是为“project”源代码管理而创建的,而是为“file”源代码管理而创建的。

• 这是缩小规模。

SP使用varbinary(max)将所有文件放在数据库中这会增加Sharepoint数据库文件的大小,而且实际占用的空间比放在磁盘上的空间要多一些。(我并不是说BLOB是邪恶的,但是当频繁使用时,它会让DB维护变得很糟糕)

但总的来说,我可以考虑的唯一好的原因是它没有与IDE集成,所以您将有很多工作要使用它。想象一下几个开发人员将他们所有的文件复制到一个sharepoint库中,这会减慢他们的速度。

最后,它不够快的开发人员不会喜欢它(更因为增加了步骤)。

Sharepoint不是源代码管理工具。有许多免费的和商业的工具正是为解决这个问题而设计的。Sharepoint不是其中之一。

我知道这些是你在你的帖子中已经陈述过的观点。我认为这应该是争论的结束。如果你不得不为这个可怕的坏主意做进一步的辩护,我无法想象他们的其他过程是什么样的。

使用SharePoint作为源版本控制:

欺骗 : -不支持重复数据消除,每个版本都是一个完整的文件夹 收到。 -无法对回滚执行完整的文件集标记-例如,如果 您希望将产品作为一个整体还原到特定的时间点。 -文件不是散列的,散列是一种现代的性能技术- 例如,git或mercurial只将哈希值与 确定文件是否相同,这非常快。

赞成的意见 使用sharepoint作为版本控制,如果您已经获得许可。

• 它为二进制文件提供线性版本控制,有时就是这样 你想要的。例如,如果要将附加到 MS文档或excel。

• 很适合没有依赖关系的二进制文件。