标签: mergeinfo

我想使用预提交挂钩,阻止开发人员在非根目录上设置svn:mergeinfo.也就是说,我想强制执行svn:mergeinfo 只能在"trunk"或"branches/branchName"这样的目录上设置.开发人员有时需要"提醒"使用根目录的子目录作为合并目标(根据此处列出的最佳实践)并不是一种好的做法.有没有人有这样的钩子脚本或知道我在哪里找到一个？我在Windows环境中,所以批处理或powershell会更好,但任何东西肯定会有所帮助.

我早就听说过svn的合并冲突问题.

当我得知svn在几个版本之前实现了一个名为的功能时,我很放心mergeinfo.似乎它的引入似乎允许svn有足够的信息来解决它们出现时的合并问题.直到我遇到以下情况:

上图的脚本示例:

SVN=${SVN:-svn}
SVNADMIN=${SVNAMDIN:-svnadmin}

rm -rf repo wc

$SVNADMIN create repo

$SVN co file://$PWD/repo wc
cd wc

# r1
$SVN mkdir trunk branches
$SVN ci -m 'structure'
$SVN up

# r2
echo 2 > trunk/t.txt
$SVN add trunk/t.txt
$SVN ci -m 'add t.txt'
$SVN up

# r3
$SVN cp trunk branches/A
$SVN ci -m 'create branch A'
$SVN up

# r4
echo 4 > branches/A/a.txt
$SVN add branches/A/a.txt
$SVN ci -m 'add a.txt'
$SVN up

# r5 …

在最新版本的git中,svn.pushmergeinfo引入了配置:

config key:svn.pushmergeinfo

此选项将导致git-svn尝试在可能的情况下自动填充SVN存储库中的svn:mergeinfo属性.目前,这只能在提交非快进合并时才能完成,其中除第一个之外的所有父级已经被推入SVN.

我们使用它来创建一个混合环境,其中一些开发人员使用SVN,一些使用Git-SVN.当在Git中分支和合并SVN分支然后git svn dcommit回到SVN时,这很有用,并且它实际上在几乎所有情况下都正确地填充了mergeinfo属性.但是,在特定情况下,它会错误地执行.

这种情况主要发生在将分支合并到主分支(主干)之后,将主干合并到该分支(实际上,相当于SVN重新整合).

从主干到分支的合并为该分支上的trunk增加了一个mergeinfo行(根据需要),但是从分支返回到trunk的reintegrate-merge复制到trunk的mergeinfo中,有效地在trunk的mergeinfo属性中创建了一个自引用行这指向了自己.据我所知,这种自我引用永远不应该发生,并且单独使用SVN时不会发生.所以,我认为这是一个git-svn错误(我在这里报告过).这反过来会产生影响其他SVN用户的问题,并在未来的提交中破坏mergeinfo.

我正在寻找的是一种解决方法:如何轻松告诉git不要为要合并的分支复制mergeinfo行,或者如何告诉SVN在提交时删除那些自引用(或任何其他解决方案导致自引用mergeinfo行,但确实保留了自动svn的其他特性:从git创建mergeinfo.

(为了澄清,我不是在寻找人们向我引用git手册或告诉我"与Git-SVN合并是危险的并且不受支持".请仅在你可以帮助解决问题或提出替代工作流程时回答.指向相关的git代码也会有所帮助,因为它们可能允许我创建一个补丁来解决这个问题.谢谢!)

使用git-svn合并svn跟踪分支的正确工作流程是什么.我已经阅读了一些关于git-svn svn.pushmergeinfo配置密钥的内容,注意事项是:

来自http://www.kernel.org/pub/software/scm/git/docs/git-svn.html:

config key:svn.pushmergeinfo

此选项将导致git-svn尝试在可能的情况下自动填充SVN存储库中的svn:mergeinfo属性.目前,这只能在提交非快进合并时才能完成,其中除第一个之外的所有父级已经被推入SVN.

所以我的正常工作流程是:

假设我有一个SVN分支^/branches/feature_branch

# Ensure git-svn is configured to populate svn:mergeinfo
git config --global svn.pushmergeinfo true   

# Update my local svn remotes state
git svn fetch

# Track a local branch against a remote SVN backed ^/branches/feature_branch 
git checkout -b local_feature_branch remotes/feature_branch

# Modify files and commit to local git repo
git commit -a -m "changes"
# Push changes to SVN branch ^/branches/feature_branch
git svn dcommit

然后将^/trunk合并到我的local_feature_branch我假设我做了类似的事情？

# Sync to the latest SVN …

我们尝试仅将'svn:mergeinfo'属性保留在根分支文件夹中.但是,我们一直看到它爬进子文件夹.我们已经找到了一些可能的原因:

1. 在repo-browser中移动文件夹
2. 在IntelliJ中移动和/或重命名包
3. 使用旧的svn客户端

任何人都可以提供我们不应该做的事情列表,以避免意外创建这些属性吗？

我们使用的工具是IntelliJ 8(很快9),Ankh,TortoiseSVN和SlikSvn.

我有Subversion 1.6.5客户端和1.5.4服务器.我大多只关心完全存储库路径上的差异,而不是工作副本.

在扩展分支时,已合并的分支已经显示为除mergeinfo属性之外的相同内容.

对于那些必须通过变化寻找可能是真正变化的任何事物的人来说,这是一种烦人的感觉.

然而,在我们的用例中它有点糟糕,因为我们有运行检查各种事物的合并状态的脚本,而mergeinfo属性使它们突出显示许多事情,因为它们不同步时不同步.

有没有办法让diff摘要忽略mergeinfo属性？

我试图通过将主干合并到分支中来保持功能分支最新.问题是,创建分支时存在的大约2000个文件,并且在分支和主干上保持不变的情况下只更新了svn:mergeinfo.该项目规模相当大,对我们的SVN历史的影响是如此之大,以至于它使合并提交历史无法使用,因为它标记了数千个文件已更改,即使这些文件的唯一更改是由SVN完成的本身.

我试过了

• 使用与Repo相同的客户端版本(1.5.2)
• 使用我当前的客户端版本1.6.10
• 合并一系列修订,从分支开始到头部

我应该提一下,在尝试这个时我一直在仔细查看SVN文档.所以不应该破坏任何规则(例如,没有切换子树,干净的本地副本等)

我想我必须遗漏一些基本的理解,这使我无法理解这一点.

在执行合并时,您希望在什么情况下使用--ignore-ancestry选项？我的理解是,使用此选项可以防止在目标分支上更新mergeinfo属性,但在什么情况下您不希望记录mergeinfo？

我正在使用最近升级到1.7版的Subversion服务器.我使用的是命令行Linux客户端1.7.10.

我创建了一个这样的分支:

%: svn copy svn+ssh://acme.com/a/b/c/trunk svn+ssh://acme.com/a/b/c/branches/ovm_sequencer -m "Feature branch for ovm_sequencer"

经过几次编辑,我试图重新融入主干并且只遇到问题:

%: svn merge --reintegrate '^/c/branches/ovm_sequencer'
svn: E160013: File not found: revision 1677, path '/c/branches/ovm_sequencer'

%: svn merge --reintegrate svn+ssh://acme.com/a/b/c/branches/ovm_sequencer
svn: E200007: Retrieval of mergeinfo unsupported by 'svn+ssh://acme.com/a/b/c/branches/ovm_sequencer'

出了什么问题,如何解决？

我们正在合并从主干到分支的变化.在我们执行此操作时,会记录合并信息.

由于分支中可能存在其他更改,是否有一种安全的方法只提交由于合并而受影响的文件(假设没有其他更改)以及合并属性/信息？

"假设我想从主干到分支合并修订版'r1'.我从主干到分支合并'r1'.现在为'r1',在分支文件夹中,记录合并信息.如果我做了在分支中的svn diff,它显示'.' 已修改,并显示'r1'是合并属性的一部分.现在我如何提交由于'r1'仅被合并而修改的文件,以及合并属性,其中显示'r1'."

新的1.8 subversion客户端有问题(我们使用TortoiseSVN 1.8.5和SlikSVN 1.8.5).似乎在重新集成后能够继续使用您的功能分支的新SVN 1.8功能在某些情况下不起作用.

当trunk包含本地mergeinfo(文件或子树上的Mergeinfo)时,它不起作用.这可能会导致重新集成后分支重用的问题.如果使用'keep alive dance'(使用仅记录选项)完成分支重用,这对1.7客户端来说不是问题.

我已经制作了一个从头开始说明这个问题的脚本.它可以使用1.8客户端针对空存储库运行.

下面的脚本有10个步骤.步骤1-5用于创建在主干中具有本地mergeinfo的起始情况.步骤6-9模拟在功能分支2的生命周期内对主干进行的更改.步骤10是失败的步骤,它模拟重新集成后重用特征分支的第一步.

这是步骤10中的错误:

svn: E195016: Reintegrate can only be used if revisions 8 through 11 were pre
viously merged from svn://svn2010/practice/branches/featurebranch2 to the reinte
grate source, but this is not the case:
  trunk/file1.txt
    Missing ranges: /trunk/file1.txt:9

这是(Windows)脚本.

@ECHO OFF
ECHO ------------------------------------------------------------------
ECHO STEP 0: Create a repository
ECHO ------------------------------------------------------------------
if exist repo rmdir repo /S/Q
if exist trunk rmdir trunk /S/Q
if exist featurebranch1 rmdir featurebranch1 /S/Q
if exist featurebranch2 rmdir featurebranch2 …

我有几个文件似乎总是svn:mergeinfo在通过合并的常规工作周期执行的各种合并任务上获得新设置.

该文件在几个月内没有变化,但是持久触摸了mergeinfo.我有一种感觉,mergeinfo在某些时候感到困惑,从未恢复过.我不知道该找什么来破解mergeinfo并纠正,或者只是删除它并继续前进.

有小费吗？

我有一个从主干开始的分支A和从A开始的分支B.定期地,从主干到A的合并,然后也执行从A到B的合并.当我想将A和B合并到主干时,我想按照这种方式:

• 重新融合从B到A的合并
• 重新整合从A到主干的合并

这是对的吗？或者它可能导致mergeinfo或其他问题的问题？在这种情况下,最佳做法是什么？