相关疑难解决方法(0)

我们目前在相对较大的代码库上使用subversion.每个版本都有自己的分支,并对主干执行修复,并使用迁移到发布分支svnmerge.py

我相信现在是时候进行更好的源代码控制了,我一直在玩Mercurial.

虽然使用Mercurial管理这样的发布结构似乎有两个学派.每个版本都有自己的repo,并且针对发布分支进行修复并推送到主分支(以及任何其他更新的发布分支.)或在单个存储库(或多个匹配副本)中使用命名分支.

在任何一种情况下,似乎我可能会使用像移植一样的东西,以包含在发布分支中的cherrypick更改.

我问你 每种方法的相对优点是什么？

我有许多准相关项目,我想版本控制.在SVN中,我将它们设置为单个项目中的多个目录

/scripts  #updates in sync with project1 & project2
/project1 #requires database
/project2 #requires database
/database

当然,这个玩具示例可以使用其他SVN布局,但这种布局具有以下优点:

• 我可以在分支之间复制文件,同时保留历史记录
• 我只能查看一部分项目,例如svn co repo/project2; svn co repo/database.如果project1很大,这可以节省大量的存储和时间.
• 易于存储库管理,因为所有项目都定义了一次用户访问权限

由于无法克隆mercurial repo的单个目录,因此这种范例不能很好地映射到mercurial .所以我的问题是:在mercurial中存储大型密切相关项目的最常用方法是什么？

我的想法:

• 多个存储库 - 丢失在项目之间移动的文件的历史记录
• 森林 - 似乎停滞不前,我不确定这个扩展是多么稳定
• 命名分支,主要是不相关的内容
• SubRepos - 不幸的是我正在运行Ubuntu 9.04,它只运送hg 1.1.2.否则这看起来是个不错的选择

最近我们遇到了一些问题,即开发人员将代码提交给SVN但没有通过单元测试,无法在所有平台上编译,甚至无法在自己的平台上编译.虽然这一切都被我们的CI服务器(巡航控制)所取代,并且我们已经制定了试图阻止它发生的流程,但我们真的希望能够阻止流氓提交首先发生.

基于此处的一些其他问题,在服务器端强制将其作为预提交挂钩似乎是一个坏主意,主要是由于构建+运行测试所需的时间长度.我做了一些谷歌搜索并发现了这个(所有开发者都使用TortoiseSVN):

http://cf-bill.blogspot.com/2010/03/pre-commit-force-unit-tests-without.html

哪个会解决至少两个问题(它不会在Unix上构建),但如果失败则不会拒绝提交.所以我的问题:

• 有没有办法在TortoiseSVN中进行预提交挂钩导致提交失败？
• 有没有更好的方法来做我一般要做的事情？