如果您使用任何较大的 Linux 发行版，那么在您的服务器上安装 Git/Mercurial/SVN 可能很容易；几乎可以肯定有现成的软件包可用。如果您预计必须使用不同的每用户访问控制来管理多个存储库，那么有一个很好的 Git 管理系统，称为 gitolite。如果没有这样的东西，管理多个存储库可能会有点麻烦。
Let's try a balanced comparison, based on the premise that in your scenario you're probably not going to need any of the advanced features anyway.
Comparison
Storage
Layout on filesystem: SVN requires two things, a working directory and a repository, for working with your data. Not only does this impose unnecessary duplication of metadata, but it makes things slightly more unwieldy. Both Git and Mercurial can keep your complete history inside the working directory (every working directory is a full repository). This is not too relevant if you don't intend on having a checked out copy of your files on the server (but it's a bit more complicated than that, anyway, so keep in mind that there might be other situations in which this whole bullet point does not apply at all).
Cluttering of working dir: SVN adds .svn subdirs in every subdir of your repository; Git and Mercurial only add a single .git/.hg directory at the top level.
Space consumption: Git and Mercurial use storage mechanisms that tends to be much more efficient than SVN's. The downside in Git is that the repository has to be optimized occasionally (which tends to be reasonably fast if you don't have extremely large files); I have no idea whether this is necessary for Mercurial but I suspect it isn't.
Conclusion: I recommend Git or Mercurial.
Features
Since you probably won't even need the way better merging capabilities of Git/Mercurial, I don't see this as a deciding factor. This does not apply if you are planning on working on several sets of changes simultaneously; in that case, Git/Mercurial will probably make things much easier on you.
Speed
Git and Mercurial are notoriously faster than SVN, especially since their design allows many operations to be performed locally.
Looking at old stuff: in SVN looking at your history of changes means that SVN has to connect to the remote repository and look there; in (for example) Git the history usually displays before SVN has even established that connection.
OS-dependent: many of Git's optimizations apply mostly to Linux; you may experience worse performance on, say, Windows. The same might be true for the other contenders to a lesser degree, I don't know.
Transmissions: Git and Mercurial send and receive new changes much more quickly than SVN in almost any scenario.
Conclusion: Git and Mercurial are preferable if you like things fast. On Windows Mercurial might be a better choice, but please consult/perform actual benchmarks if you want to be sure.
DVCS
Git and Mercurial allow developers to continue working on their things, and organise them in a sensible set of commits, even if they are not currently connected to your network. In SVN, commits can only be made at the same time as they end up on the server, so SVN users tend to use more monolithic (and thus more difficult to understand) commits. At least Git, on the other hand, even has a tool for quickly finding the commit that introduced a bug, using binary search. Again, SVN might come out on the bottom here.
Complexity
I'm a huge fan of Git and I'll easily agree that Git is not the most user-friendly VCS, at least if you don't understand its design. For more advanced use cases, I believe that the toolchain makes up for that; in your case, you might prefer Mercurial or SVN unless you expect to be using the same VCS for more complex projects in the future.
Tools, interfaces
I don't know Mercurial very well, so I'm not very familiar with what interfaces there exist for it. In fact I don't use any fancy-shmancy interfaces for Git, either, but I believe that there are plenty of tools for all of the contenders that allow basic usage for, shall we say, people who don't appreciate command lines. However, I'd strongly recommend that you do a bunch of small tests before you spring anything specific on your team.
Your questions
Repositories tend to be structured differently for the different systems. In SVN it's okay to have a whole bunch of projects inside the same repository; Git and Mercurial strongly prefer having one repository per project. For shared code, Git has at least three tools (two of them third-party) for using external repositories, Mercurial probably has something as well. I know SVN has something like that, anyway.
If you do manage them as individual repositories, I would probably recommend Git or Mercurial because, as already said, they tend to have less overhead per repository.
Installing Git/Mercurial/SVN on your server is probably easy if you use any of the bigger Linux distributions; there are almost certainly ready-made packages available. If you anticipate having to manage a number of repositories with different per-user access control, there is a nice management system for Git called gitolite. Managing several repositories can be a bit of a hassle without something like that.
I would say don't use SVN because in my opinion the DVCS ability to do branching and merging is almost essential. Having never used hg I would recommend git. To learn git give the first couple chapters here a read.
After you get it setup I would just setup a different repo for each site and use a development branch with git and just merge it to master when you are ready to launch. Check out gitflow for a bit more on a workflow for using git.
That is a post about the workflow and a link is on there if you want to install extensions for git. There is also a couple of video tutorials around on using it as well.
You might also checkout tekpub for their git series if you are more of a visual learner.
If all you're doing is local development (that is, within your network.. not just on one machine), then SVN is probably the best solution. Even if you have a few distributed developers, if all they need to do is connect to a central repository and check files in and out then SVN is a fine tool. Certainly, SVN has it's own quirks and gotchas.
GIT adds a ton of complexity, and it has a very high learning curve because they tend to redefine comon workflows and even meanings of common vcs terms. Plus, GIT adds extra steps to the process (syncronizing local repositories with the server). SVN has more mature IDE integration, and the tools work a lot more smoothly. TortoiseGIT is not very mature yet.
If you decide you want to move to GIT later, there's lots of tools to import SVN into GIT, so there will be no lost work.
GIT is designed to allow lots of disparate people to work independantly and then merge and syncronize their changes. If you don't need that, use SVN.
GIT has a number of advantages over SVN, but SVN also has it's advantages. For example, SVN uses diffs, while GIT uses snapshots. This means GIT repositories can be much larger SVN repositories with the same data in them. Basically, GIT stores each changed copy of the file in its entirety, while SVN only stores the delta. Make one change in GIT to a 1MB file, and it stores another 1MB file. make one change in SVN to a 1MB file, then only the change (plus some overhead) is stored. Depending on the kind of data you're storing, this can be significant.
Svn vs. git is well into holy war territory, and therefore really off topic, not to mention frequently duplicated. Your branching model question is much more amenable to objective answers, though. Here are some general guidelines:
Code that is common between websites should be drawn from a single official repository. If you ever find yourself going outside your source control to propagate the same change, like copying and pasting a file between folders, it's not set up correctly.
Code that is customized for different websites should ideally be architected so it's in separate directories from the common code. This makes common and custom code fairly independent, which lets you assemble your configuration using git submodules or svn partial checkouts.
If you can't separate the architecture for historical reasons, you can maintain a branch with each individual website's customizations. However, whenever you make a change to the common code that you need to propagate to all sites, you run a much higher risk of merge conflicts that must be manually resolved. You also have to be careful in which branch you make common code changes. Note that the possibility of merge conflicts isn't really a good excuse to forgo source control branches altogether. Your architecture means those conflicts are happening anyway, so you may as well let your source control help you out with the merge. That way you only have to worry about the real conflicts.
First off, AFAIK SVN is the only one that will allow you to store all your sites in a single repo and selectively check them out individually (see sparse checkouts). DVCSs (by their off-line, all-local nature) rely on the entire repo to be present.
The next thing to note is that git support on Windows is .. not what most Windows users are used to, and I'm led to believe that TortoiseGit isn't 100% ready for prime time. Mercurial is probably a better choice for a Windows DVCS.
I think the thing you need to do is sit down and work out the workflow your team uses - how much merging do you do, how much parallel development, how much is your master repo used as a definitive source, how much offline work do you do, etc. If you don't do any of the things that DVCSs excel at, then SVN is probably the better choice for you - better tools and simpler to understand usage. If you do some of the things that SVN isn't good at (offline working, massive amounts of refactoring) then I'd probably go with Mercurial.
发布评论
评论（6）
让我们尝试进行平衡比较，前提是在您的场景中您可能不需要任何高级功能。
比较
文件系统上的存储
工作目录混乱：SVN 在存储库的每个子目录中添加
.svn子目录； Git 和 Mercurial 仅在顶层添加一个.git/.hg目录。空间消耗：Git 和 Mercurial 使用的存储机制往往比 SVN 更高效。 Git 的缺点是存储库必须偶尔进行优化（如果您没有非常大的文件，优化速度往往相当快）；我不知道这对于 Mercurial 是否有必要，但我怀疑不是。
结论：我推荐 Git 或 Mercurial。
特性
由于您可能甚至不需要 Git/Mercurial 更好的合并功能，因此我不认为这是一个决定因素。如果您计划同时进行多组更改，则这不适用；在这种情况下，Git/Mercurial 可能会让你的事情变得更容易。
Speed
Git 和 Mercurial 是出了名的比 SVN 快，特别是因为它们的设计允许许多操作在本地执行。
查看旧内容：在 SVN 中查看更改历史意味着 SVN 必须连接到远程存储库并查看那里；在（例如）Git 中，历史记录通常在 SVN 建立连接之前显示。
依赖于操作系统：Git 的许多优化主要适用于 Linux；例如，您可能会在 Windows 上遇到性能较差的情况。我不知道其他竞争者的情况也可能在较小程度上如此。
传输：在几乎任何情况下，Git 和 Mercurial 发送和接收新更改的速度都比 SVN 快得多。
结论：如果您喜欢快速操作，Git 和 Mercurial 是更好的选择。在 Windows 上，Mercurial 可能是更好的选择，但如果您想确定的话，请咨询/执行实际基准测试。
DVCS
Git 和 Mercurial 允许开发人员继续处理他们的事情，并将它们组织在一组合理的提交中，即使他们当前没有连接到您的网络。在 SVN 中，提交只能在它们最终到达服务器的同时进行，因此 SVN 用户倾向于使用更多单一的（因此更难以理解）提交。另一方面，至少 Git 甚至有一个工具可以使用二分搜索快速查找引入错误的提交。再次强调，SVN 可能会垫底。
复杂性
我是 Git 的忠实粉丝，并且我很容易同意 Git 不是最用户友好的 VCS，至少如果您不了解它的设计的话。对于更高级的用例，我相信工具链可以弥补这一点；根据您的情况，您可能更喜欢 Mercurial 或 SVN，除非您希望将来在更复杂的项目中使用相同的 VCS。
工具、接口
我不太了解Mercurial，所以我不太熟悉它有哪些接口。事实上，我也不使用任何花哨的 Git 界面，但我相信所有竞争者都有很多工具，可以让那些不喜欢命令行的人进行基本使用。但是，我强烈建议您在为团队提供任何特定内容之前先进行一些小测试。
您的问题
对于不同的系统，存储库的结构往往不同。在 SVN 中，同一存储库中可以有一大堆项目； Git 和 Mercurial 强烈喜欢每个项目拥有一个存储库。对于共享代码，Git 至少有三个用于使用外部存储库的工具（其中两个是第三方），Mercurial 可能也有一些工具。无论如何，我知道 SVN 有类似的东西。
如果您确实将它们作为单独的存储库进行管理，我可能会推荐 Git 或 Mercurial，因为正如已经说过的，它们每个存储库的开销往往较小。
如果您使用任何较大的 Linux 发行版，那么在您的服务器上安装 Git/Mercurial/SVN 可能很容易；几乎可以肯定有现成的软件包可用。如果您预计必须使用不同的每用户访问控制来管理多个存储库，那么有一个很好的 Git 管理系统，称为 gitolite。如果没有这样的东西，管理多个存储库可能会有点麻烦。
Let's try a balanced comparison, based on the premise that in your scenario you're probably not going to need any of the advanced features anyway.
Comparison
Storage
Layout on filesystem: SVN requires two things, a working directory and a repository, for working with your data. Not only does this impose unnecessary duplication of metadata, but it makes things slightly more unwieldy. Both Git and Mercurial can keep your complete history inside the working directory (every working directory is a full repository). This is not too relevant if you don't intend on having a checked out copy of your files on the server (but it's a bit more complicated than that, anyway, so keep in mind that there might be other situations in which this whole bullet point does not apply at all).
Cluttering of working dir: SVN adds
.svnsubdirs in every subdir of your repository; Git and Mercurial only add a single.git/.hgdirectory at the top level.Space consumption: Git and Mercurial use storage mechanisms that tends to be much more efficient than SVN's. The downside in Git is that the repository has to be optimized occasionally (which tends to be reasonably fast if you don't have extremely large files); I have no idea whether this is necessary for Mercurial but I suspect it isn't.
Conclusion: I recommend Git or Mercurial.
Features
Since you probably won't even need the way better merging capabilities of Git/Mercurial, I don't see this as a deciding factor. This does not apply if you are planning on working on several sets of changes simultaneously; in that case, Git/Mercurial will probably make things much easier on you.
Speed
Git and Mercurial are notoriously faster than SVN, especially since their design allows many operations to be performed locally.
Looking at old stuff: in SVN looking at your history of changes means that SVN has to connect to the remote repository and look there; in (for example) Git the history usually displays before SVN has even established that connection.
OS-dependent: many of Git's optimizations apply mostly to Linux; you may experience worse performance on, say, Windows. The same might be true for the other contenders to a lesser degree, I don't know.
Transmissions: Git and Mercurial send and receive new changes much more quickly than SVN in almost any scenario.
Conclusion: Git and Mercurial are preferable if you like things fast. On Windows Mercurial might be a better choice, but please consult/perform actual benchmarks if you want to be sure.
DVCS
Git and Mercurial allow developers to continue working on their things, and organise them in a sensible set of commits, even if they are not currently connected to your network. In SVN, commits can only be made at the same time as they end up on the server, so SVN users tend to use more monolithic (and thus more difficult to understand) commits. At least Git, on the other hand, even has a tool for quickly finding the commit that introduced a bug, using binary search. Again, SVN might come out on the bottom here.
Complexity
I'm a huge fan of Git and I'll easily agree that Git is not the most user-friendly VCS, at least if you don't understand its design. For more advanced use cases, I believe that the toolchain makes up for that; in your case, you might prefer Mercurial or SVN unless you expect to be using the same VCS for more complex projects in the future.
Tools, interfaces
I don't know Mercurial very well, so I'm not very familiar with what interfaces there exist for it. In fact I don't use any fancy-shmancy interfaces for Git, either, but I believe that there are plenty of tools for all of the contenders that allow basic usage for, shall we say, people who don't appreciate command lines. However, I'd strongly recommend that you do a bunch of small tests before you spring anything specific on your team.
Your questions
Repositories tend to be structured differently for the different systems. In SVN it's okay to have a whole bunch of projects inside the same repository; Git and Mercurial strongly prefer having one repository per project. For shared code, Git has at least three tools (two of them third-party) for using external repositories, Mercurial probably has something as well. I know SVN has something like that, anyway.
If you do manage them as individual repositories, I would probably recommend Git or Mercurial because, as already said, they tend to have less overhead per repository.
Installing Git/Mercurial/SVN on your server is probably easy if you use any of the bigger Linux distributions; there are almost certainly ready-made packages available. If you anticipate having to manage a number of repositories with different per-user access control, there is a nice management system for Git called gitolite. Managing several repositories can be a bit of a hassle without something like that.
我想说不要使用 SVN，因为在我看来，DVCS 进行分支和合并的能力几乎是必不可少的。从未使用过 hg 我会推荐 git。要学习 git，请阅读这里的前几章。
http://progit.org/book/
设置完成后，我将为每个设置一个不同的存储库站点并使用 git 的开发分支，然后在准备启动时将其合并到 master 中。查看 gitflow，了解有关使用 git 的工作流程的更多信息。
http://nvie.com/posts/a-successful-git-branching- model/
这是一篇关于工作流程的文章，如果你想安装 git 扩展，那里有一个链接。还有一些有关使用它的视频教程。
如果您是视觉学习者，您也可以查看 tekpub 的 git 系列。
祝
你好运。
I would say don't use SVN because in my opinion the DVCS ability to do branching and merging is almost essential. Having never used hg I would recommend git. To learn git give the first couple chapters here a read.
http://progit.org/book/
After you get it setup I would just setup a different repo for each site and use a development branch with git and just merge it to master when you are ready to launch. Check out gitflow for a bit more on a workflow for using git.
http://nvie.com/posts/a-successful-git-branching-model/
That is a post about the workflow and a link is on there if you want to install extensions for git. There is also a couple of video tutorials around on using it as well.
You might also checkout tekpub for their git series if you are more of a visual learner.
http://tekpub.com/productions/git
Good luck.
如果您所做的只是本地开发（即在您的网络内......而不仅仅是在一台机器上），那么 SVN 可能是最好的解决方案。即使您有一些分布式开发人员，如果他们所需要做的就是连接到中央存储库并签入和签出文件，那么 SVN 也是一个很好的工具。当然，SVN 有它自己的怪癖和陷阱。
GIT 增加了大量的复杂性，并且它的学习曲线非常高，因为它们倾向于重新定义常见的工作流程，甚至常见 vcs 术语的含义。另外，GIT 向该过程添加了额外的步骤（将本地存储库与服务器同步）。 SVN有更成熟的IDE集成，工具运行起来也流畅很多。 TortoiseGIT还不是很成熟。
如果您决定稍后要迁移到 GIT，有很多工具可以将 SVN 导入到 GIT，因此不会丢失工作。
GIT 的设计目的是允许许多不同的人独立工作，然后合并并同步他们的更改。如果不需要，请使用 SVN。
GIT 比 SVN 有很多优点，但 SVN 也有它的优点。例如，SVN 使用差异，而 GIT 使用快照。这意味着 GIT 存储库可以是更大的 SVN 存储库，其中包含相同的数据。基本上，GIT 完整地存储文件的每个更改副本，而 SVN 仅存储增量。在 GIT 中对一个 1MB 文件进行一项更改，它会存储另一个 1MB 文件。在 SVN 中对 1MB 文件进行一项更改，则仅存储更改（加上一些开销）。根据您存储的数据类型，这可能很重要。
If all you're doing is local development (that is, within your network.. not just on one machine), then SVN is probably the best solution. Even if you have a few distributed developers, if all they need to do is connect to a central repository and check files in and out then SVN is a fine tool. Certainly, SVN has it's own quirks and gotchas.
GIT adds a ton of complexity, and it has a very high learning curve because they tend to redefine comon workflows and even meanings of common vcs terms. Plus, GIT adds extra steps to the process (syncronizing local repositories with the server). SVN has more mature IDE integration, and the tools work a lot more smoothly. TortoiseGIT is not very mature yet.
If you decide you want to move to GIT later, there's lots of tools to import SVN into GIT, so there will be no lost work.
GIT is designed to allow lots of disparate people to work independantly and then merge and syncronize their changes. If you don't need that, use SVN.
GIT has a number of advantages over SVN, but SVN also has it's advantages. For example, SVN uses diffs, while GIT uses snapshots. This means GIT repositories can be much larger SVN repositories with the same data in them. Basically, GIT stores each changed copy of the file in its entirety, while SVN only stores the delta. Make one change in GIT to a 1MB file, and it stores another 1MB file. make one change in SVN to a 1MB file, then only the change (plus some overhead) is stored. Depending on the kind of data you're storing, this can be significant.
svn 与 git 已经进入了圣战领域，因此确实偏离了主题，更不用说经常重复了。不过，您的分支模型问题更适合客观答案。以下是一些一般准则：
Svn vs. git is well into holy war territory, and therefore really off topic, not to mention frequently duplicated. Your branching model question is much more amenable to objective answers, though. Here are some general guidelines:
首先，据我所知 SVN 是唯一一个允许您将所有站点存储在一个存储库中并有选择地单独签出它们的软件（请参阅稀疏签出）。 DVCS（由于其离线、全本地的性质）依赖于整个存储库的存在。
接下来要注意的是，Windows 上的 git 支持并不是大多数 Windows 用户所习惯的，而且我相信 TortoiseGit 还没有 100% 准备好迎接黄金时段。 Mercurial 可能是 Windows DVCS 的更好选择。
我认为你需要做的就是坐下来制定你的团队使用的工作流程 - 你做了多少合并，多少并行开发，你的主存储库用作最终来源有多少，你做了多少离线工作如果您不做 DVCS 所擅长的任何事情，那么 SVN 可能是您更好的选择 - 更好的工具并且更容易理解用法。如果你做一些 SVN 不擅长的事情（离线工作、大量重构），那么我可能会选择 Mercurial。
First off, AFAIK SVN is the only one that will allow you to store all your sites in a single repo and selectively check them out individually (see sparse checkouts). DVCSs (by their off-line, all-local nature) rely on the entire repo to be present.
The next thing to note is that git support on Windows is .. not what most Windows users are used to, and I'm led to believe that TortoiseGit isn't 100% ready for prime time. Mercurial is probably a better choice for a Windows DVCS.
I think the thing you need to do is sit down and work out the workflow your team uses - how much merging do you do, how much parallel development, how much is your master repo used as a definitive source, how much offline work do you do, etc. If you don't do any of the things that DVCSs excel at, then SVN is probably the better choice for you - better tools and simpler to understand usage. If you do some of the things that SVN isn't good at (offline working, massive amounts of refactoring) then I'd probably go with Mercurial.
Git 是你最好的选择。您可能需要更多的学习曲线，但最终您的工作效率会更高。
Git is your best option. You may have a bit more of a learning curve but you'll end up more productive in the end.