对于家庭项目，Mercurial或Git（或其他DVCS）可以提供比Subversion更多的优势吗？ [英] For home projects, can Mercurial or Git (or other DVCS) provide more advantages over Subversion?

问题描述

哪个免费源代码控制系统最适合家庭项目和文档？

我正在考虑使用Subversion（因为我很熟悉它）。

家庭项目的特点：$ b​​
$ b

1. 提交更改。
   （可能是一天（不是现在），我可能与我在其他城市的朋友分享项目）




2. 我想要存储其他文件（非编程文件）
   





Mercurial或GIT（分布式版本控制系统）可以给我更多优势在颠覆家庭项目？

解决方案

在我回答 GIT和CVS之间的区别StackOverflow上的问题。其中一些问题仍然适用于Subversion和Git（或其他分布式VCS：Mercurial，Bazaar，或不太知名的：Monotone，Darcs），即使Subversion对CVS的改进也是如此。



免责声明：我使用Git（所以我有偏见），并且只从文档（和其他资源）知道Subversion，从来没有使用过它自己。我可能会误解Subversion的功能。

下面列出了单个开发人员在单机（单一账户）上的Git和Subversion之间的区别：






• 建立资料库。Git将资料库储存在 .git 目录放在项目的顶层目录中。从没有版本控制的文件树开始一个新项目就像在项目的顶部目录中执行git init一样简单（然后当然是git add。来添加文件，例如git commit -m'Initial commit' ）创建第一次提交。

  
  
  在Subversion中（在任何集中式版本控制系统中），您需要使用svnadmin create设置中央存储库（当然，你只需要做一次）。然后，您必须使用svn import（或svn add）将文件导入到Subversion中。但请注意，导入完成后，原始树不会被转换为工作副本。要开始工作，您仍需要svn checkout树的新工作副本。
• Git在 .git 目录中的 顶部目录 。
  
  

  Subversion将存储库存储在单独的区域中，您必须为此存储这些信息，并存储存储库元数据（例如，中央存储库的位置，用于联系中央存储库的身份，我认为像 svn：ignore 这样的属性也存储在 每个目录中的 .svn 目录中 em> 您的项目。 （请注意，Subversion存储您的结帐的原始副本，以获得快速的svn status和svn diff）

  strong>命名修订/版本号。 Subversion使用全局修订标识符，以单个数字指定版本的形式（例如，您可以参考r344，修订版344）。 Subversion还支持一些符号修订说明符：HEAD，BASE，COMITTED，PREV。
  
  
  

  在Git中，每个版本的项目（每个提交） hexdigits SHA-1 id;通常前7-8个字符足以识别提交（不能在分布式版本控制系统中使用简单编号方案 - 需要中央编号权限）。但Git还提供了其他类型的修订说明符，例如 HEAD ^ 表示当前提交的父项， master〜5 意味着修订版本5的祖先（在直接的第一条母行中）从顶层提交到主分支， v1.6.3-rc2 可能意味着修订标记为 v1.6.3-rc2 。

  
  
  

  另见许多不同种类的修订说明符 Elijah Newren的博客文章。




• 轻松分支和合并。在Git创建和合并分支中非常容易; Git自己记得所有需要的信息（所以合并一个分支就像git merge branchname一样容易）......它不得不这样做，因为分布式开发自然会导致多个分支。 Git使用启发式基于相似性的重命名检测，所以它在合并时可以处理一方重命名文件（以及与重命名相关的其他类似情况）的情况。这意味着您可以使用主题分支工作流，即在单独的功能分支的多个步骤中开发单独的功能。

  
  
  

  分支具有在Subversion中不寻常的实现;它们由命名空间约定处理：分支是在特定名称空间内存在的全局储存库中的修订的组合。通过将现有的一组文件从一个名称空间复制到另一个名称空间来创建新分支，并将其记录为修订本身。 Subversion很容易创建新的分支......但是，直到1.5版本，您必须使用额外的工具（如SVK或svnmerge扩展）才能轻松地 merge 。 Subversion 1.5引入了 svn：mergeinfo 属性，但即使如此，合并比Git稍微复杂一点;你还需要使用额外的选项来显示和利用诸如svn log和svn blame等工具中的合并跟踪信息。我听说它在更复杂的情况下无法正常工作（交叉合并），并且目前无法处理重命名（在这种情况下甚至有可能发生沉默腐败）。参见（例如）这篇文章在Git邮件列表由Dmitry Potapov解释了用于 svn：mergeinfo 及其（当前）限制。

标签 > ，可以有与其相关的评论，并且可以使用PGP / GPG签名（并已验证）进行签名。他们使用git标签制作。您可以使用标签名称参考修订版。




在Subversion标签中，使用与分支相同的类似path_info的名称空间 convention （推荐约定为 svnroot / project / tags / tagname ），并且不受保护而不会改变。他们使用svn copy制作。它们可以有与[创建标签的提交]相关的注释。

关键字扩展关键字与Subversion相比（默认情况下）。这是因为两个事实：Git中的更改是每个存储库而不是每个文件，并且Git避免修改切换到其他分支或回顾历史中其他点时未更改的文件。如果你想使用Git嵌入修订版本号，你应该使用你的构建系统来完成这个工作。遵循Linux内核源代码和Git源代码中的GIT-VERSION-GEN脚本的实例。还有'ident' gitattribute，它允许将$ Id $关键字扩展为文件内容的SHA-1标识符提交）。





Git和Subversion都只根据请求进行关键字扩展。 二进制文件。 Git和Subversion都能正确处理二进制文件。 Git使用类似的算法来执行二进制文件检测，例如， GNU diff，除非使用gitattributes在每个路径上重写。 Subversion通过在添加文件和设置 svn：mime-type 属性期间检测文件的类型，稍微改变一些方法，然后修改。根据需要，Git和Subversion都可以执行 行尾字符转换 ; Git另有 core.safecrlf 配置选项，它警告和防止不可逆转的变化（所有CR到所有CRLF都是可逆的，混合CR和CRLF不可逆）。 $ c>文件，可以放在版本控制和分发之下;它通常包含用于构建产品和其他生成文件的模式，并且在 .git / info / excludes 文件中通常包含特定于用户或系统的忽略模式。忽略编辑器备份文件的pattersn。 Git模式递归地应用，除非patter包含目录分隔符，即正斜杠字符'/'，那么它锚定到目录 .gitignore 文件是;顶部目录为 .git / info / excludes 。 （还有 core.excludesfile 配置变量;这个变量可以存在于每个用户〜/ .gitconfig 配置文件中，并指向每个用户的忽略文件）。
$ b

Subversion使用 global-ignores 运行时配置选项适用于特定计算机或计算机的特定用户）以及SVN版本目录中的 svn：ignore 属性。然而，不同于 global-ignores 选项（并且在 .gitignore 中）， svn：ignore 属性仅适用于设置了该属性的目录，而不适用于其任何子目录。另外，Subversion不会识别使用！前缀作为异常机制的模式。 strong>修改提交。分布式VCS（例如Git）的发布操作与创建提交不同，可以更改（编辑，重写）未发布的历史记录部分，而不会给其他用户带来不便。特别是如果你注意到提交信息中的错字（或其他错误）或提交中的错误，你可以简单地使用git commit --amend。 （注意：从技术上讲，它重新创建一个提交，而不是改变现有的提交;改变后的提交具有不同的标识符）。

。



Subversion只允许通过改变适当的属性来修改提交消息。


• 工具一方面，Git提供了更丰富的命令集。更重要的一点是git bisect，可用于查找引入错误的提交（修订版）;如果你的提交很小并且自成一体，那么应该很容易找到bug的位置。另一方面，Subversion因为存在时间更长，可能更宽一套第三方工具，以及工具中的Subversion支持，而不是Git。或者至少比较成熟。特别是在MS Windows上。
  
  
  
  
  $ b

  另外还有一个问题，后面可能会比较重要：

  
  
  
  
  

  • 发布资料库。如果将它从单个家庭计算机上开发的单人项目转变为其他贡献的东西，使用Git就像在服务器上创建空的存储库或在git支持的现有git托管站点/软件托管站点之一（如< a href =http://repo.or.cz =nofollow noreferrer> http://repo.or.cz ， GitHub ， Gitorious ，InDefero;更多 - 也适用于其他DVCS - 已列出在回答），然后将您的项目推送到此公共存储库。 / p>
    
    

    我想这是比较复杂的Subversion，如果你从一开始就没有从拥有Subversion支持的软件托管站点（如SourceForge）开始，除非你不想保留现有的修订历史。另一方面，例如Google Code建议使用 svnsync 工具（标准Subversion发行版的一部分），如 Google产品> Project Hosting（数据解放阵线）一文。

  
  > http://whygitisbetterthanx.com/ 网站。
  

  Which free source control system is most preferable with reason for home projects and documents?

  I am thinking to use Subversion (as I am familiar with it).

  Characteristic of home project:

  1. Most likely single person will be committing changes. (May be one day (not now), it is possible that I share a project with my friend who is in other city)

  2. I would like to store other documents (non-programming files)

  Is Mercurial or GIT (distributed version control system) can give me any more advantage over to subversion in Home Projects?

  解决方案

  Take a look at part about version control for single developer in my answer to "Difference between GIT and CVS" question here on StackOverflow. Some of those issues do still apply also to Subversion versus Git (or other distributed VCS: Mercurial, Bazaar, or less known: Monotone, Darcs), even if Subversion is improvement over CVS.

  DISCLAIMER: I use Git (so I am biased), and know Subversion only from documentation (and other resources), never having used it myself. I might be then mistaken about Subversion capabilities.

  Below there are list of differences between Git over Subversion for a single developer, on single machine (single account):

  • Setting up repository. Git stores repository in .git directory in top directory of your project. Starting a new project from unversioned tree of files is as easy as doing "git init" in a top directory of your project (and then of course "git add ." to add files, and e.g. "git commit -m 'Initial commit'" to create first commit).

    In Subversion (in any centralized version control system) you need to set up central repository (unless you did that earlier) using "svnadmin create" (well, you need to do that only once). Then you have to import files into Subversion using "svn import" (or "svn add")... But note that after the import is finished, the original tree is not converted into a working copy. To start working, you still need to "svn checkout" a fresh working copy of the tree.

  • Repository and repository metadata. Git stores both repository (i.e. information about revisions and branches, etc.) and repository metadata (e.g. your identity, list of ignored files, which branch is currently checked out) in .git directory in top directory of your projects.

    Subversion stores repository in separate area you have to put for that purpose, and stores repository metadata (e.g. where central repository is, identity used to contact central repository, and I think also properties like svn:ignore) are stored in .svn directory in each directory of your project. (Note that Subversion stores pristine copy of your checkout, to have fast "svn status" and "svn diff")

  • Naming revisions / version numbers. Subversion uses global revision identifiers in the form of single number specifying revision (so you can for example refer to r344, revision 344). Subversion also supports a few symbolic revision specifiers: HEAD, BASE, COMITTED, PREV.

    In Git each version of a project (each commit) has its unique name given by 40 hexdigits SHA-1 id; usually first 7-8 characters are enough to identify a commit (you can't use simple numbering scheme for versions in distributed version control system -- that requires central numbering authority). But Git offers also other kinds of revision specifiers, for example HEAD^ means parent of a current commit, master~5 means revision 5 ancestors back (in straight first-parent line) from top commit on a 'master' branch, v1.6.3-rc2 might mean revision tagged v1.6.3-rc2.

    See also Many different kinds of revision specifiers blog post by Elijah Newren.

  • Easy branching and merging. In Git creating and merging branches is very easy; Git remembers all required info by itself (so merging a branch is as easu as "git merge branchname")... it had to, because distributed development naturally leads to multiple branches. Git uses heuristic similarity-based rename detection, so it while merging it can deal with the case where one side renamed file (and other similar cases related to renaming). This means that you are able to use topic branches workflow, i.e. develop a separate feature in multiple steps in separate feature branch.

    Branches have an unusual implementation in Subversion; they are handled by a namespacing convention: a branch is the combination of revisions within the global repository that exist within a certain namespace. Creating a new branch is done by copying an existing set of files from one namespace to another, recorded as a revision itself. Subversion made it easy to create new branch... but up till version 1.5 you had to use extra tools such as SVK or svnmerge extensions to be able to merge easily. Subversion 1.5 introduced svn:mergeinfo property, but even then merging is slightly more complicated than in Git; also you need to use extra options to show and make use of merge tracking information in tools such as "svn log" and "svn blame". I have heard that it doesn't work correctly in more complicated situations (criss-cross merge), and cannot deal currently with renames (there is even chance of silent corruption in such case). See also (for example) this post on git mailing list by Dmitry Potapov, explaining intended use case for svn:mergeinfo and its (current) limitations.

  • Tagging. In Git tags are immutable, can have comment associated with them, and can be signed using PGP/GPG signature (and verified). They are made using "git tag". You can refer to revision using tag name.

    In Subversion tags use the same path_info-like namespace convention as branches (recommended convention is svnroot/project/tags/tagname), and are not protected against changing. They are made using "svn copy". They can have comment associated with [the commit creating a tag].

  • Keyword expansion. Git offers very, very limited set of keywords as compared to Subversion (by default). This is because of two facts: changes in Git are per repository and not per file, and Git avoids modifying files that did not change when switching to other branch or revinding to other point in history. If you want to embed revision number using Git, you should do this using your build system, e.g. following exaple of GIT-VERSION-GEN script in Linux kernel sources and in Git sources. There is also 'ident' gitattribute which allows expansion of "$Id$" keyword to SHA-1 identifier of file contents (not identifier of a commit).

    Both Git and Subversion do keyword expansion only on request.

  • Binary files. Both Git and Subversion deal correctly woth binary files. Git does binary file detection using similar algorithm to the one used by e.g. GNU diff, unless overriden on per-path basis using gitattributes. Subversion does it in slightly different way, by detecting type of file during adding file and setting svn:mime-type property, which you can then modify. Both Git and Subversion can do end of line character conversion on demand; Git has additionally core.safecrlf config option which warn and prevent irreversible change (all CR to all CRLF is reversible, mixed CR and CRLF is not reversible).

  • Ignoring files. Git stores ignore patterns using in-tree .gitignore file, which can be put under version control and distributed; it usually contain patterns for build products and other generated files, and in .git/info/excludes file, which usually contains ignore patterns specific to user or system, e.g. ignore pattersn for backup files of your editor. Git patterns apply recursively, unless patter contain directory delimiter i.e. forward slash character '/', then it is anchored to directory .gitignore file is; to top dir for .git/info/excludes. (There is also core.excludesfile configuration variable; this variable can exist in per-user ~/.gitconfig configuration file, and point to per-user ignore file).

    Subversion uses global-ignores runtime configuration option (which generally apply to particular computer or by a particular user of a computer), and "svn:ignore" property on SVN-versioned directories. However unlike the global-ignores option (and in .gitignore), the patterns found in the "svn:ignore" property apply only to the directory on which that property is set, and not to any of its subdirectories. Also, Subversion does not recognize the use of the ! prefix to pattern as exception mechanism.

  • Amending commits. distributed VCS such as Git act of publishing is separate from creating a commit, one can change (edit, rewrite) unpublished part of history without inconveniencing other users. In particular if you notice typo (or other error) in commit message, or a bug in commit, you can simply use "git commit --amend". (Note: technically it is re-creating a commit, not changing existing commit; the changed commit has different identifier).

    Subversion allows only to modify commit message after the fact, by changing appropriate property.

  • Tools. On one hand Git offers richer set of commands. One of more important is "git bisect" that can be used to find a commit (revision) that introduced a bug; if your commits are small and self-contained it should be fairly easy then to discover where the bug is.

    On the other hand, Subversion because exists longer, has perhaps wider set of third party tools, and Subversion support in tools, than Git. Or at least more mature. Especially on MS Windows.

  ---

  And there is another issue, which might be quite important later:

  • Publishing repository. If (when?) at some time you would want to share your repository, turning it from one-person project developed on a single home computer, to something other contribute, with Git is as simple as creating empty repository on server or on one of existing git hosting sites / software hosting sites with git support (like http://repo.or.cz, GitHub, Gitorious, InDefero; more--also for other DVCS--are listed in that answer), and then pusing your project to this public repository.

    I guess it is more complicated with Subversion, if you don't start at software hosting site with Subversion support (like SourceForge) from the beginning, unless you don't want to preserve existing revision history. On the other hand for example Google Code suggest to use svnsync tool (part of the standard Subversion distribution), as explained in Google Products‎ > ‎Project Hosting (the Data Liberation Front) article.

  ---

  Take a look also at http://whygitisbetterthanx.com/ site.

  这篇关于对于家庭项目，Mercurial或Git（或其他DVCS）可以提供比Subversion更多的优势吗？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！