对于OS项目是srvn，对于企业项目是svn? [英] mercurial for OS projects and svn for Enterprise projects?

问题描述

如果我做错了，请纠正我，但是分布式SCM是否适合OS项目，而集中式SCM是否更适合公司/私有项目?

correct me if im wrong, but isn't distributed SCMs for OS projects while centralized SCMs are better for corporate/private projects?

原因与毫无疑问，任何人都可以获得具有完整历史记录功能的存储库的精确副本，而集中化则只能获取最新的工作副本.

cause with eg. mercurial anyone gets an exact copy of the repository with FULL history features, while with centralized you only get the latest working copy.

我更专注于私人项目，所以我想知道对于集中式SCM来说是否更好?

im more focused on private projects so i wonder if its better with centralized SCMs or doesnt it matter?

推荐答案

您可以使用大型公司中的DVCS(如水银).

与VCS相比，DVCS的限制基本上是:

The limits of a DVCS compared to a VCS are essentially:

• 尺寸 (您不能将所有内容无限期地存储在DVCS中，这意味着您应该重新考虑开发数据所有权很难管理. /li>
• 工作流程:即使DVCS工作流程可以

• size (you cannot indefinitely stored everything in a DVCS, meaning you should rethink your development data as modules instead of a monolithic set of files which can still be found in large projects)
• right access management: it is not as fine-grained in a DVCS as it can be in VCS, essentially because many external parties can contribute to a project, with different user authentication schemes. The ownership is trickier to manage.
• workflow: a DVCS workflow is more complex even if it can emulate the one of a CVCS (one central repo acting as reference for all others)

也就是说， DVCS允许一种新的发布方式 (拉/拉)数据，这些数据可帮助团队间的预交付"(当团队希望共享开发，即使仍在进行中且尚未正式致力于中央存储库时):您成为被动生产且活跃的消费者

That said, DVCS allows for a new way to publish (pull/pull) data, which can help for inter-teams "pre-deliveries" (when a team want to share development even though there are still in progress and not yet officially committed to the central repository): you become a passive produced and an active consumer.

Tomislav Nakic-Alfirevic 在评论中询问:

您能否举例说明将DVC与集中式DVC进行比较的第二点?

Could you illustrate your second point comparing a DVC with a centralized one?

正确的访问管理非常棘手，特别是在大型企业中:

The right access management is tricker, especially if the large corporation:

• 必须与外部企业共享其某些存储库以进行共享的外包开发
• 允许将其某些存储库克隆到个人计算机上(当在不同站点上的移动环境中工作时，开发人员并不总是可以访问企业网络)

在这些情况下，这意味着:

In those cases, that means:

• 用户身份验证并不总是很容易协调(同一用户可以根据其克隆存储库的位置而具有不同的身份).可以设置基于SSH的身份验证(gitosis， gitauth ).
• 通过其他工具的元数据不受透明支持)
  (文件名中的特殊字符可能有问题)
• 访问权限通常仅限于所有存储库，而不是按每个分支或每个文件(例如本地管理为此，必须配置git的rel ="nofollow noreferrer"> gitolite ，而不是始终具有服务器的CVS，这意味着将更倾向于提出更细粒度的ACL)

• the user authentication is not always easy to reconcile (a same user can have different identity depending on where he/she clones the repository). A SSH-based authentication can be setup (gitosis, gitauth).
• the metadata associated with the file are limited, through Git tags for instance
  (the group of a file for instance might not exist on a given computer where the repo is cloned)
  (metadata from other tools are not transparently supported)
  (special characters in filenames can be problematic)
• the access rights are often limited to the all repository and not natively managed per branch or per file (a server like gitolite for Git must be configured for that, as opposed to a CVS which always has a server, meaning which will be more enclined to propose a finer-grained ACL)

实例太简单了 直接回答大型公司的问题:

Git for instance is a bit too simple to answer directly large corporation concerns:

刚接触git的人(意思是，我刚开始也曾建议过类似的增强功能；))经常谈论添加此功能或该功能，而没有意识到git真的非常非常简单.
它具有文件，目录，提交，标签和就这样.
集中式解决方案的强大之处在于替代标识符(例如a)的 lack 分支路径，服务器分配的序列号等.

People new to git (meaning, I was suggesting enhancements like this when I started too ;)) frequently talk about adding this feature or that feature, without realising that git really is very very simple.
It has files, directories, commits, tags and that's it.
It's power over centralized solutions is the lack of surrogate identifiers such as a branch path, server assigned sequence number, etc.

是的，可能会有更多的关系和元数据来表示很多事情.
每个文件的历史记录和合并，目录重命名，挑选，还原.
但是，所有这些都给基本模型增加了复杂性，该基本模型已经显示出能够处理这些问题的能力-注意事项.
但是回报-简单-值得那些警告.

Yes, there could be more relationships and metadata to represent a whole lot of things.
Per-file history and merging, directory renaming, cherry picking, reverting.
But these all add complications to the basic model, which has already shown itself to be capable of dealing with these things - with caveats.
But the pay-off - simplicity - is well worth those caveats.

这篇关于对于OS项目是srvn，对于企业项目是svn?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！