小商店，为什么选择 DVCS？
我们有一个小型编程车间，最多有 5 个人从事一个项目。我完全理解为什么 DVCS 对于开源项目和大公司来说更好，但除了“你可以在飞机上工作”之外，它对小公司还有什么优势。这将需要额外的 SA 工作来确保我们在 DEV 盒上的存储库每晚都得到正确备份。
我们还有一些非技术人员（艺术家、翻译人员）可以（在某种程度上）处理 SVN，根据人们的经验，需要多少培训才能让他们迁移到 DVCS？
We have a small programming shop of at most 5 people working on a single project. I fully grok why DVCS is better for open source projects, and for large companies, but what advantages does it have for smaller companies other than "you can work on the airplane." Which would require extra SA work to make sure that our repositories on DEV boxes was properly backed up every night.
We also a have several non technical people (artists, translators) who can (sort of) deal with SVN, in peoples experience how much training is required to get them to move to a DVCS?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我将根据我的经验来谈谈，主要是使用 SVN 和 Hg，经常与不熟悉版本控制的设计师和程序员一起工作。
我对 SVN 和我使用过的其他 CVCS 的最大不满是，它们会阻止你进行提交，不仅是在网络中断时，而且在发生冲突的情况下（或更糟糕的是，有人锁定了一个文件，这样其他人就无法提交）对其进行更改！）。您当然可以提交到一个分支，但是在切换分支所需的网络带宽和合并所涉及的痛苦之间，您仍然遇到问题。
当然，SVN 会阻止您提交冲突的文件，这样您就不会意外覆盖其他人的工作； SVN 要求您至少承认您知道一个版本或另一个版本（或两者的自定义组合）是正确的。然而，Mercurial 有一个更好的解决方案（实际上是 2）：
1. 您始终可以立即提交到本地存储库并稍后合并。 （所有 DVCS 都具有此功能。）
2. 即使您拉或推有冲突的更改，您也不会被阻止提交，而是通过匿名分支拥有多个头。 （抱歉，我无法在这里详细解释这一点，但您可以通过谷歌搜索。）
因此您的工作流程如下：
1. 获取最新信息、进行更改并进行测试。
2. 获取最新信息，解决冲突，测试结果。
3. 承诺。
并变为：
1. 获取最新信息、进行更改并进行测试。
2. 承诺（这样你就有一个可以依靠的地方）。
3. 获取最新信息，解决冲突，测试结果。
4. 承诺并推动。
额外的提交意味着每次提交要做的工作更少，因此您有更多的检查点可以依靠。还有其他方法可以让您做出更多承诺而不妨碍其他人。
SVN 太慢了，足以分散我的注意力并诱惑我去 Facebook； Mercurial 速度很快，git 更快。在查看日志或对工作副本进行更改时，速度问题变得非常重要。借助 TortoiseHg，我可以单击文件列表，然后立即查看该文件的更改；使用 TortoiseSVN + WinMerge 处理每个文件大约需要几秒钟（不确定其中有多少是由于 DVCS 造成的）。我使用这些工具越多，我就越觉得 VCS 需要足够快，就像文本编辑器或鼠标光标一样——足够快，以至于不需要网络来完成它。
主观上，我发现 TortoiseHg 比 TortoiseSVN（或我使用过的其他乌龟）更容易使用。 TortoiseHg 也是多平台的。 :)
还有一件事：据我了解，SVN 工作副本是递归定义的：每个文件夹都是一个工作副本。这允许您做一些奇特的事情（例如，拥有一个包含来自存储库中不同位置的文件夹的工作副本）。我不知道 Hg 是否有类似的功能，但根据我的经验，SVN 实现此功能只会在我工作的地方引起问题，特别是对于那些不太熟悉 SVN 的人。当他们通过 OS shell 而不是通过 svn copy 在计算机上复制并粘贴 WC 文件夹时，他们的 WC 就会出现问题。我家厕所也是这样搞砸的。对于 Hg 来说这不是一个问题——你通常会同时使用整个存储库，无论是克隆、更新还是提交。
I'm going to speak from my experience, which is primarily with SVN and Hg, often working with designers and programmers who are not comfortable with version control.
My big beef with SVN and other CVCS's I've used is that they block you from making commits, not just when the network is down, but also in case of a conflict (or worse, someone locking a file so no one else can make changes to it!). You could of course commit to a branch, but between network bandwidth required to switch branches and the pain involved in merging, you still have a problem.
Of course, SVN blocks you from committing conflicted files so that you don't accidentally overwrite someone else's work; SVN requires you to at least acknowledge that you know one version or the other (or a custom combination of the two) is right. Mercurial, however, has a better solution (2, actually):
1. You can always commit to the local repository now and merge later. (All DVCS's have this feature.)
2. Even if you pull or push conflicting changes, instead of being blocked from committing, you have multiple heads via anonymous branches. (Sorry I can't really explain this in detail here, but you can google it.)
So your workflow goes from:
1. Get the latest, make changes, test them.
2. Get the latest, resolve conflicts, test the result.
3. Commit.
and becomes:
1. Get the latest, make changes, test them.
2. Commit (so you have a place to fall back to).
3. Get the latest, resolve conflicts, test the result.
4. Commit and push.
That extra commit means you're doing less work per commit, so you have more checkpoints to fall back on. And there are other ways you can make more commits without getting in others' way.
SVN is just slow enough to break my concentration and tempt me to go to facebook; mercurial is fast and git is faster. The speed issue becomes very important when reviewing a log or changes to a working copy. With TortoiseHg, I can click through a list of files, and instantly see changes to that file; it takes about a couple seconds per file with TortoiseSVN + WinMerge (not sure how much of this is due to the DVCS). The more I use these tools, the more I feel that a VCS needs to be fast, just like a text editor or a mouse cursor--fast enough that you shouldn't require the network to do it.
Subjectively, I find TortoiseHg to be a heck of a lot easier to use than TortoiseSVN (or other tortoises I've used). TortoiseHg is mutli-platform, too. :)
One more thing: As I understand, a SVN working copy is defined recursively: Each folder is a working copy. This allows you to do some fancy-pants stuff (e.g. having a working copy that contains folders from disparate locations in the repository). I don't know if Hg has a similar feature, but in my experience, SVN's implementation of this feature causes only problems where I work, especially for those not quite comfy with SVN. When they copy-and-paste a WC folder on their machine via the OS shell instead of via svn copy, it goofs up their WC. I've goofed up my WC this way as well. It's less of a problem with Hg--you normally work with an entire repo at once, whether you clone, update, or commit.
自从发布以来，SVN 在合并方面有了很大的改进。但它仍然缺乏文件重命名跟踪，常常导致树冲突。 重命名是分布式版本控制的杀手级应用解决了这个问题，在评论部分添加了一些有趣的链接。
与 Subversion 相比，DVCS 允许您推送到中央存储库，但需要多一条命令。临时用户应该能够适应工作流程中的这一微小变化。但是，为高级用户提供“本地”提交和分支的自由，而不会使中央存储库变得混乱。
就工具而言，这对于用户接受度可能很重要，Mercurial 与 Subversion 不相上下。
SVN improved a lot concerning merging since its release. But it still lacks file rename tracking, often resulting in tree conflicts. Renaming is the killer app of distributed version control tackles this issue, adding some interesting links in the comment section.
DVCS lets you push to a central repository, at the cost of one additional command compared to Subversion. Occasional users should be able to adapt to this minor change in workflow. But giving the freedom of 'local' commits and branches to power users without cluttering a central repository.
Concerning tooling, which might be of importance for user acceptance, Mercurial is on par with Subversion.