我正在与仍在运行 1.4 版的第 3 方 Subversion 存储库进行交互,让它们升级的可能性几乎为零。所以,当然,我在这个存储库中的工作是我做过的一些最繁重的合并工作,而且我没有任何合并信息可以使用。
任何人都可以推荐一个好的工作流程来跟踪 1.4 存储库中的分支和合并吗?带有提交消息和/或属性的东西?还有什么?
我正在与仍在运行 1.4 版的第 3 方 Subversion 存储库进行交互,让它们升级的可能性几乎为零。所以,当然,我在这个存储库中的工作是我做过的一些最繁重的合并工作,而且我没有任何合并信息可以使用。
任何人都可以推荐一个好的工作流程来跟踪 1.4 存储库中的分支和合并吗?带有提交消息和/或属性的东西?还有什么?
David 是对的,Subversion 没有在 1.4 中内置任何合并跟踪支持。但是,有一个svnmerge脚本,当前的 Subversion 合并跟踪功能是根据该脚本建模的。一些项目,如 Python,成功地使用它来维护长期和短期分支。
根据项目的不同,使用bzr-svn、git-svn或hg-subversion可能会让你更接近你正在寻找的东西。IMO,bzr-svn 工作得相当好,并且支持真正的分支合并(另一个要求您使用 rebase 工作流程)。我已经在几个项目中成功使用了它,但有一些警告。例如,如果您的项目使用外部工具,那么使用这些工具中的任何一个的故事就没有那么吸引人了,因为它们都不支持外部工具。
Subversion 1.4 没有原生的合并跟踪。由于 Subversion 有一个本地 API,一些第三方客户端很可能有一个内置的合并跟踪器。
在 1.5 之前,您应该通过添加合并信息作为提交消息的一部分来跟踪合并。您还试图避免从项目的根目录之外的任何地方进行挑选和合并。否则,事情很快就会变得相当复杂。
我会使用标签来标记我的合并点。例如,我会有一个标记5.1->trunk
,标记我从 5.1 分支到主干的最后一个合并点。寻找标签而不是通过 SVN 日志寻找合并评论要容易得多。
我想您也可以使用该svn:merge-info
属性,因为它没有在您的 Subversion 版本中使用。如果您将其格式化为标准 svn:mergeinfo 属性格式,可能会很有帮助。也许有一天,它们会升级,而您的“svn:mergeinfo”属性可能会对您有所帮助。
再说一次,这可能是你不应该使用 svn:mergeinfo 属性的完美理由。弄乱它的格式,他们升级的 1.5 后版本的 Subversion 也会抛出 conniptions。你最好使用类似的东西,local:mergeinfo
直到你的服务器升级(如果它曾经升级过)。