对于家庭项目,Mercurial或Git(或其他DVCS)可以提供比Subversion更多的优势吗？

Question

家庭项目和文件的理由最适合哪种免费的源控制系统？

我正在考虑使用Subversion(因为我熟悉它).

家居项目的特点:

1. 最有可能是单身人士会做出改变.(可能是一天(不是现在),我可能与我在其他城市的朋友分享项目)

2. 我想存储其他文件(非编程文件)

Mercurial或GIT(分布式版本控制系统)能否比家庭项目中的颠覆更具优势？

Answer 1

在StackOverflow上我在回答" GIT和CVS之间的差异 "问题时,看一下有关单个开发人员版本控制的部分内容.其中一些问题仍然适用于Subversion与Git(或其他分布式VCS:Mercurial,Bazaar或鲜为人知:Monotone,Darcs),即使Subversion是对CVS的改进.

免责声明:我使用Git(所以我有偏见),只从文档(和其他资源)知道Subversion,从未自己使用它.我可能会误解Subversion功能.

下面列出了单个开发人员(单个帐户)上单个开发人员的Git over Subversion之间的差异:

• 设置存储库.Git将存储库存储在.git项目顶层目录的目录中.从无版本的文件树开始一个新项目就像在项目的顶层目录中执行"git init"一样简单(然后当然是"git add."来添加文件,例如"git commit -m'初始提交' "创建第一次提交.

  在Subversion(在任何集中式版本控制系统中),你需要使用"svnadmin create"设置中央存储库(除非你之前做过)(嗯,你只需要这样做一次).然后你必须使用"svn import"(或"svn add")将文件导入Subversion ......但请注意,导入完成后,原始树不会转换为工作副本.要开始工作,你仍然需要"svn checkout"树的新工作副本.

• 存储库和存储库元数据.Git .git在项目的顶级目录中的目录中存储存储库(即有关修订和分支的信息等)和存储库元数据(例如,您的标识,被忽略文件列表,当前已检出的分支).

  Subversion将存储库存储在您必须为此目的而放置的单独区域中,并存储存储库元数据(例如,中央存储库的位置,用于联系中央存储库的标识,我认为还有属性svn:ignore)存储在项目的每个目录中的.svn目录中.(请注意,Subversion存储结帐的原始副本,具有快速"svn status"和"svn diff")

• 命名修订版/版本号.Subversion以指定版本的单个数字的形式使用全局修订标识符(因此您可以参考r344,修订版344).Subversion还支持一些符号修订说明符:HEAD,BASE,COMITTED,PREV.

  在Git中,项目的每个版本(每个提交)都有40个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扩展,才能轻松合并.Subversion 1.5引入了svn:mergeinfo属性,但即使这样,合并也比Git稍微复杂一些; 您还需要使用额外的选项来显示和使用"svn log"和"svn blame"等工具中的合并跟踪信息.我听说它在更复杂的情况下(criss-cross merge)无法正常工作,并且目前无法处理重命名(在这种情况下甚至有可能出现静默腐败).另请参阅(例如)Dmitry Potapov 在git邮件列表上的这篇文章,解释预期用例svn:mergeinfo及其(当前)限制.

• 标记.在Git中,标签是不可变的,可以有与之关联的注释,并且可以使用PGP/GPG签名(并经过验证)进行签名.它们是使用"git tag"制作的.您可以使用标签名称来引用修订版.

  在Subversion标记中,使用与分支相同的类似path_info的命名空间约定(推荐的约定是svnroot/project/tags/tagname),并且不受保护以防止更改.它们是使用"svn copy"制作的.他们可以与[创建标签的提交]相关联的评论.

• 关键字扩展.与Subversion(默认情况下)相比,Git提供非常有限的关键字集.这是因为两个事实: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配置选项,可以警告并防止不可逆转的变化(所有CRLF的CR都是可逆的,混合CR和CRLF是不可逆的).

• 忽略文件.Git存储使用in-tree .gitignore文件忽略模式,可以将其置于版本控制和分发之下; 它通常包含构建产品和其他生成文件的模式,以及.git/info/excludes文件中,通常包含特定于用户或系统的忽略模式,例如忽略编辑器备份文件的pattersn.Git模式递归应用,除非模式包含目录定界符,即正斜杠字符'/',然后它锚定到目录.gitignore文件是; 顶级导演.git/info/excludes.(还有core.excludesfile配置变量;此变量可以存在于每个用户的~/.gitconfig配置文件中,并指向每个用户的忽略文件).

  Subversion使用global-ignores运行时配置选项(通常适用于特定计算机或计算机的特定用户),以及svn:ignoreSVN版本目录上的" "属性.但是与global-ignores选项(和in .gitignore)不同," svn:ignore"属性中的模式仅适用于设置该属性的目录,而不适用于其任何子目录.此外,Subversion不承认使用!前缀来模式化为异常机制.

• 修改提交. 分布式VCS(如Git发布行为)与创建提交是分开的,可以更改(编辑,重写)未发布的历史部分,而不会给其他用户带来不便.特别是如果你发现提交消息中的拼写错误(或其他错误),或提交中的错误,你可以简单地使用"git commit --amend".(注意:从技术上讲,它是重新创建提交,而不是更改现有提交;更改的提交具有不同的标识符).

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

• 工具.一方面,Git提供了更丰富的命令.其中一个更重要的是"git bisect",可用于查找引入错误的提交(修订); 如果您的提交很小并且自包含,那么应该很容易发现错误的位置.

  另一方面,Subversion因为存在时间较长,可能有更广泛的第三方工具集,而Subversion支持工具,而不是Git.或者至少更成熟.特别是在MS Windows上.

还有另一个问题,后来可能会非常重要:

• 发布存储库. 如果(何时？)在某个时候您想要共享您的存储库,将其从在单个家用计算机上开发的单人项目转换为其他贡献的东西,使用Git就像在服务器上或在其中一个上创建空存储库一样简单现有主机与Git支持网站的git托管网站/软件(如http://repo.or.cz,GitHub上,Gitorious,InDefero;更多-也为其他DVCS -中列出这个问题的答案),然后你的Pusing项目到这个公共存储库.

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

另请参阅http://whygitisbetterthanx.com/网站.

Answer 2

一个明显的好处是:当您离开服务器时可以开发.例如,您可能有一台笔记本电脑拥有自己的本地git存储库,并推送到您的服务器(或github).现在假设你去了一个没有互联网连接的地方...在Subversion你必须做的事情没有任何提交,直到你再次连接.使用DVCS,您可以在本地提交(并恢复,分支等),然后在您回家时将这些提交备份.

Answer 3

在"家庭项目"设置中,git和mercurial的一个非常强大的优势是新的存储库很容易设置.在git中,您只需git init在代码树的根目录下执行操作即可获得新的存储库.

然后,您可以立即添加,提交,分支等.svn设置成本较高,因为在创建工作副本并启动常规VCS操作之前,您需要一个单独的存储库位置和URL.

存储文件在git或mercurial中没有问题,但肯定是使用git(不确定hg)我会建议不要存储大型媒体文件(从100M向上),因为它在某些操作中往往表现不佳.

Answer 4

我在个人项目中使用git来"与自己合作".我在家庭网络上的Linux机器上有存储库,可以从任何地方通过隧道访问.然后我将它克隆到我的家用台式机,我的笔记本电脑,也许是工作中的机器,我可以看到它或在我去的任何地方工作.我可以提交更改,获取最新信息,并在各个地方进行备份.git允许您切换分支的简易性和速度非常好.发现了一个bug？切换到'master',修复它,commit,push,然后切换回你正在做的事情.比cvs或颠覆更容易和更快.

另外,我对很多甚至不是项目的小目录都使用git.托管我的网站的apache服务器的配置目录是git'd,同样是同一网站的tomcat配置目录.

我在工作中使用它来做所有事情,即使在工作中我们正在使用CVS转向Subversion.我不使用git-cvs或git-svn,我只是使用git和任一产品,并保持我的分支本地.非常方便能够切换到另一个开发人员的最新提交,检查一下,然后切换回来.

然后,当然,对于工作或家庭项目,这可能是一个巨大的帮助.

此外,如果在工作中他们仍然使用穿孔卡,cvs或颠覆,那么在家使用git是保持最新状态的好方法,并找出它可能产生的影响.

我不会对技术感到兴奋,除非他们带来真正的新东西.Git呢.我是一个粉丝.你可能已经想到了这一点.

Answer 5

除了关于hg,git,darcs,bzr和朋友的许多精彩功能的细节(没有讽刺;我是一个巨大的粉丝),必需品在这里:

• 使用svn,您必须选择将您的repo存储在异地并将其存储在现场. 现场意味着如果您的磁盘发生故障,您的项目就是吐司.非现场意味着您无法从飞机或其他断开连接的情况下提交,并且当网络连接不良时,提交可能会很慢.

• 对于任何分布式VCS,创建"repo"的一个或多个"克隆" 是微不足道的.您可以随时快速地在本地提交更改,然后在连接可用时将这些更改推送到远程仓库.

git,hg和其他版本都加载了与svn和cvs不同的特性(和错误特征).但这些都是必需品.