为什么我不应该使用SharePoint进行源代码管理？

Question

我刚刚开始在一家没有任何源代码控制的公司工作。我提出我们可能需要进行某种源控制，我的一位同事建议我们使用SharePoint。我认为他喜欢这个主意，因为我们已经使用了sharepoint，他是一个很棒的SharePoint人员。

我想出了为什么我们不应该这样做的原因。

• SharePoint并非旨在成为代码的源代码管理工具。
• 这项工作有更好的（现在仍然是免费的）工具
• 您不能使用sharepoint进行自动部署（据我所知）
• 它不会与任何IDE集成（据我所知）

当我在为我的案子辩护时，还有什么我应该包括的吗？

Answer 1

为什么使用sharepoint作为一个愚蠢的控制是愚蠢的想法：

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

Answer 2

许可成本......您可以获得许多工具，这些工具的成本要低得多（即使他们在免费工具上嗤之以鼻），成本与SP相同。

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

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

Answer 3

SP的另一个问题是，如果有人删除了某些版本，SharePoint并不会保留删除它们的完整历史记录（据我所知）。

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

Answer 4

成本可能不是问题 - SP Foundation是免费的。不过，这不是一个好主意。

Answer 5

SP不与IDE集成，因此CheckIN，CheckOut将是手动的。

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

SP无法创建分支（仅通过手动创建新文件夹并手动告知开发人员使用新分支）。 （根据开发人员的数量，这将非常困难）

SP将每个更改视为独立于其他更改，因此无法查看时间轴中的更改。这是因为SP源不是用于“项目”源代码控制，它是为“文件”源代码控制而制作的。

• 这是缩小尺寸。

SP使用varbinary（max）将所有文件放在数据库上，这会增加Sharepoint Database文件的大小，实际上它比在磁盘上占用的空间要多一些。 （我不是说BLOB是邪恶的，但是当它被大量使用时，它会使数据库维护HELL）

但总的来说，我能想到的唯一理由是它没有与IDE集成，所以你将有很多工作要使用它。想象一下，几个开发人员将他们的所有文件复制到sharepoint库，这会减慢他们的速度。

最后它的速度不够快，开发者不会喜欢它（更多的是因为增加的步骤）。

Answer 6

Sharepoint不是源代码控制工具。有许多免费和商业工具专门针对这个问题而设计。 Sharepoint不是其中之一。

我意识到这些是您在帖子中已经说过的要点。我认为这应该是争论的结束。如果你不得不进一步防范这个可怕的坏主意，我无法想象其余的过程是什么样的。

Answer 7

使用SharePoint作为源版本控制：

缺点：  -不支持重复数据删除，每个版本都是一个文件夹，已满    复制。  -无法为回滚做完整的文件集标签-例如，如果    您想将整个产品还原到特定的时间点。  -不对文件进行哈希处理，哈希是一种提高性能的现代技术-    例如git或mercurial仅将哈希值与    确定文件是否相同，这非常快。

专业人士 如果您已经拥有许可，则使用sharepoint作为版本控制。

• 它为二进制文件提供线性版本控制，有时仅此而已 你要。例如，如果您要对附加到 MS doc或excel。

• 适合没有依赖性的二进制文件。